FHEM Forum

FHEM => Sonstiges => Thema gestartet von: Wzut am 19 Februar 2017, 19:10:09

Titel: Modul 96_SIP
Beitrag von: Wzut am 19 Februar 2017, 19:10:09
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.
Titel: Antw:Modul 96_SIP
Beitrag 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?

Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 19 Februar 2017, 19:36:22
Mir fehlen dazu die Möglichkeiten, aber plin hat das für sein Dooline Projekt zusammen mit Asterisk laufen.
Titel: Antw:Modul 96_SIP
Beitrag 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).

Titel: Antw:Modul 96_SIP
Beitrag von: Tobbi am 19 Februar 2017, 20:00:58
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 19 Februar 2017, 20:02:13
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)
Titel: Antw:Modul 96_SIP
Beitrag von: tklein am 19 Februar 2017, 20:07:43
Hallo,

wie/wo binde ich die *.pm Datei ein?

-->  erledigt, habe es nachgelesen
Titel: Antw:Modul 96_SIP
Beitrag 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.

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.
Titel: Antw:Modul 96_SIP
Beitrag von: Tobbi am 19 Februar 2017, 20:24:34
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
Titel: Antw:Modul 96_SIP
Beitrag von: det. am 19 Februar 2017, 20:58:06
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?
Titel: Antw:Modul 96_SIP
Beitrag 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.
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.   
Titel: Antw:Modul 96_SIP
Beitrag von: hdiessner am 20 Februar 2017, 19:13:31
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 20 Februar 2017, 19:54:32
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 :)
Titel: Antw:Modul 96_SIP
Beitrag von: tklein am 20 Februar 2017, 20:09:12
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?
Titel: Antw:Modul 96_SIP
Beitrag von: betateilchen am 20 Februar 2017, 20:35:22
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)
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 20 Februar 2017, 20:41:18
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 :)
Titel: Antw:Modul 96_SIP
Beitrag von: tklein am 20 Februar 2017, 21:00:20
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?

Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 20 Februar 2017, 21:39:05
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
 
Titel: Antw:Modul 96_SIP
Beitrag von: Gisbert am 21 Februar 2017, 07:49:58
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 21 Februar 2017, 08:53:00
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Gisbert am 21 Februar 2017, 09:27:43
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.
Titel: Antw:Modul 96_SIP
Beitrag von: JoWiemann am 21 Februar 2017, 10:09:06
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
Titel: Antw:Modul 96_SIP
Beitrag von: tklein am 21 Februar 2017, 14:26:39
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
Titel: Antw:Modul 96_SIP
Beitrag von: YellowBall am 21 Februar 2017, 15:51:33
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...

Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 21 Februar 2017, 16:11:53
@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 ?
Titel: Antw:Modul 96_SIP
Beitrag von: YellowBall am 21 Februar 2017, 16:19:02
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.
Titel: Antw:Modul 96_SIP
Beitrag von: tklein am 21 Februar 2017, 16:22:12
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?
Titel: Antw:Modul 96_SIP
Beitrag von: det. am 21 Februar 2017, 17:46:40
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!
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 21 Februar 2017, 17:57:28
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 :)
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 21 Februar 2017, 18:14:48
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 21 Februar 2017, 18:38:28
@tklein,
die Registrierungsprobleme hatte ich am Anfang auch, deshalb habe ich denen im Wiki schon einen eigenen Abschnitt gegönnt.
Titel: Antw:Modul 96_SIP
Beitrag von: frank am 21 Februar 2017, 18:50:14
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.
Titel: Antw:Modul 96_SIP
Beitrag von: tklein am 21 Februar 2017, 19:16:19
@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.
Titel: Antw:Modul 96_SIP
Beitrag von: betateilchen am 21 Februar 2017, 19:19:01
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 21 Februar 2017, 19:42:33
@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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 21 Februar 2017, 21:25:56
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.
Titel: Antw:Modul 96_SIP
Beitrag von: hartenthaler am 22 Februar 2017, 18:39:06
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.


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?
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 22 Februar 2017, 18:51:20
@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.
Titel: Antw:Modul 96_SIP
Beitrag von: DerTom am 22 Februar 2017, 19:23:42
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
Titel: Antw:Modul 96_SIP
Beitrag von: DerTom am 22 Februar 2017, 19:36:28
...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

Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 22 Februar 2017, 20:34:56
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 :)
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 22 Februar 2017, 20:52:58
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.
Titel: Antw:Modul 96_SIP
Beitrag von: onkeltom am 22 Februar 2017, 20:53:16
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
Titel: Antw:Modul 96_SIP
Beitrag 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.
Titel: Antw:Modul 96_SIP
Beitrag von: hartenthaler am 22 Februar 2017, 20:57:19
@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:
also #12 oder #13 oder ... #21 oder #23 oder ... oder #98.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 22 Februar 2017, 21:07:32
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.
Titel: Antw:Modul 96_SIP
Beitrag von: onkeltom am 22 Februar 2017, 21:35:02
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 22 Februar 2017, 21:39:27
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.
Titel: Antw:Modul 96_SIP
Beitrag von: onkeltom am 22 Februar 2017, 21:53:12
Vielen Dank,

ich werde es morgen früh testen und Dir dann eine Rückmeldung geben.

Gruß,
Thomad
Titel: Antw:Modul 96_SIP
Beitrag von: onkeltom am 23 Februar 2017, 10:39:34
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
Titel: Antw:Modul 96_SIP
Beitrag 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 ?

Titel: Antw:Modul 96_SIP
Beitrag von: onkeltom am 23 Februar 2017, 15:25:22
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
Titel: Antw:Modul 96_SIP
Beitrag 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.

VG plin
Titel: Antw:Modul 96_SIP
Beitrag von: fred2412 am 23 Februar 2017, 20:10:35
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
Titel: Antw:Modul 96_SIP
Beitrag von: frank am 23 Februar 2017, 20:22:07
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 24 Februar 2017, 07:22:30
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 24 Februar 2017, 11:01:20
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. 
Titel: Antw:Modul 96_SIP
Beitrag von: frank am 24 Februar 2017, 14:17:28
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
Titel: Antw:Modul 96_SIP
Beitrag von: DerTom am 25 Februar 2017, 10:27:08
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

Titel: Antw:Modul 96_SIP
Beitrag von: jorge am 25 Februar 2017, 12:43:58
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 25 Februar 2017, 13:53:53
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 ? 

Titel: Antw:Modul 96_SIP
Beitrag von: Bastelbernd am 25 Februar 2017, 14:18:15
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
Titel: Antw:Modul 96_SIP
Beitrag von: jorge am 25 Februar 2017, 15:00:05
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 25 Februar 2017, 16:57:27
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 .....
Titel: Antw:Modul 96_SIP
Beitrag von: f-zappa am 25 Februar 2017, 18:24:19
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...
Titel: Antw:Modul 96_SIP
Beitrag von: DerTom am 25 Februar 2017, 19:37:58
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 25 Februar 2017, 19:45:43
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.
Titel: Antw:Modul 96_SIP
Beitrag von: DerTom am 26 Februar 2017, 10:16:43
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.
Titel: Antw:Modul 96_SIP
Beitrag von: frank am 26 Februar 2017, 12:03:38
@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?
Titel: Antw:Modul 96_SIP
Beitrag von: DerTom am 26 Februar 2017, 13:30:38
@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.
Titel: Antw:Modul 96_SIP
Beitrag von: frank am 26 Februar 2017, 14:12:22
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.
Titel: Antw:Modul 96_SIP
Beitrag von: DerTom am 26 Februar 2017, 16:28:34
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
Titel: Antw:Modul 96_SIP
Beitrag von: hartenthaler am 26 Februar 2017, 16:41:56
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.
Titel: Antw:Modul 96_SIP
Beitrag von: DerTom am 26 Februar 2017, 17:15:34
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 26 Februar 2017, 17:25:46
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 ?
Titel: Antw:Modul 96_SIP
Beitrag von: f-zappa am 26 Februar 2017, 23:35:35
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 27 Februar 2017, 17:01:37
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 27 Februar 2017, 19:09:08
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)
 
Titel: Antw:Modul 96_SIP
Beitrag von: neo_owl am 27 Februar 2017, 20:21:06
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 27 Februar 2017, 21:18:11
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.
Titel: Antw:Modul 96_SIP
Beitrag von: frank am 28 Februar 2017, 17:45:00
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);
Titel: Antw:Modul 96_SIP
Beitrag von: det. am 28 Februar 2017, 18:37:41
bei mir leider dto.
der Platz im Passwordfile nach SIP_TELEFON_passwd: ist leer
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 28 Februar 2017, 18:46:59
Abhilfe schafft die $subcmd = -... Zeile


...
  elsif ($cmd eq "password")
  {
    $subcmd  = (defined($a[2])) ? $a[2] : "";
    return SIP_storePassword($name,$subcmd);
  }
...


VG plin
Titel: Antw:Modul 96_SIP
Beitrag von: frank am 28 Februar 2017, 20:51:54
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 28 Februar 2017, 22:06:24
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 28 Februar 2017, 22:10:58
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.
Titel: Antw:Modul 96_SIP
Beitrag von: hartenthaler am 28 Februar 2017, 23:02:29
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.
Titel: Antw:Modul 96_SIP
Beitrag von: DerTom am 01 März 2017, 17:30:10
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?
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 01 März 2017, 17:37:05
Hast du dir mal die CPU-Auslastung deines Cubietruck während des Anrufes angeschaut?
Titel: Antw:Modul 96_SIP
Beitrag von: DerTom am 01 März 2017, 17:40:47
Oha! Laut top geht die Auslastung von fhem auf 100%...das ist doch mal ein Ansatz. Wie kommt das?
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 01 März 2017, 17:42:30
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.
Titel: Antw:Modul 96_SIP
Beitrag von: frank am 01 März 2017, 17:53:26
habt ihr eventuell viele fhem instanzen (forks) parallel am laufen.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 01 März 2017, 17:56:22
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.
Titel: Antw:Modul 96_SIP
Beitrag von: DerTom am 01 März 2017, 19:19:01
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...
Titel: Antw:Modul 96_SIP
Beitrag von: frank am 01 März 2017, 19:28:44
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.
Titel: Antw:Modul 96_SIP
Beitrag von: DerTom am 01 März 2017, 19:38:17
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...
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 01 März 2017, 20:02:14
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.
Titel: Antw:Modul 96_SIP
Beitrag von: frank am 02 März 2017, 09:47:40
Zitatnur 5 ? bei mir sind es ein paar mehr ..... :)
bei mir ist der listen-prozess der erste permanente fork.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 03 März 2017, 13:14:28
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'
Titel: Antw:Modul 96_SIP
Beitrag von: f-zappa am 03 März 2017, 14:03:27
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!!!
Titel: Klasse-Modul!
Beitrag von: nageniil am 03 März 2017, 18:33:24
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...'
Titel: Antw:Modul 96_SIP
Beitrag von: franky08 am 03 März 2017, 19:25:32
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 03 März 2017, 20:14:41
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 ?
Titel: Antw:Modul 96_SIP
Beitrag von: franky08 am 03 März 2017, 20:19:18
Ja, die 192.168.2.1 ist die Fritte habe es schon mit sip_registrar fritz.box und mit der IP versucht.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 03 März 2017, 20:43:02
Probier mal sip_port 5070
Titel: Antw:Modul 96_SIP
Beitrag von: franky08 am 03 März 2017, 21:03:27
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...
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 03 März 2017, 21:19:16
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 ?
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 03 März 2017, 21:22:53
Die andere Frage ist: kann das Device sich beim listen an der Fritzbox anmelden?
Titel: Antw:Modul 96_SIP
Beitrag von: franky08 am 03 März 2017, 21:28:43
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 ERROR

Das scheint zu funktionieren, nur leider klingelt bei einem Anruf jetzt kein Telefon mehr?

VG
Frank
Titel: Antw:Modul 96_SIP
Beitrag von: franky08 am 03 März 2017, 21:53:59
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 03 März 2017, 21:56:09
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 ...
Titel: Antw:Modul 96_SIP
Beitrag von: franky08 am 03 März 2017, 22:03:54
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
Titel: Antw:Modul 96_SIP
Beitrag von: franky08 am 03 März 2017, 22:35:37
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
Titel: Antw:Modul 96_SIP
Beitrag von: franky08 am 03 März 2017, 22:56:47
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  ;)
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 03 März 2017, 23:15:01
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?
Titel: Antw:Modul 96_SIP
Beitrag von: franky08 am 03 März 2017, 23:20:38
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 04 März 2017, 08:24:29
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 04 März 2017, 08:27:28
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
Titel: Antw:Modul 96_SIP
Beitrag von: franky08 am 04 März 2017, 08:33:40
Ja, hatte mit apt-get installiert, nicht über cpan. cpan hab ich auf meinem System nicht installiert.
Titel: Antw:Modul 96_SIP
Beitrag 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 :

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
Titel: Antw:Modul 96_SIP
Beitrag von: floflo am 04 März 2017, 23:01:19
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.
Titel: Antw:Modul 96_SIP
Beitrag von: franky08 am 04 März 2017, 23:58:32
Zitates geht auch ohne intstalliertes cpan

Joh, der Tipp war Gold wert...
Titel: Antw:Modul 96_SIP
Beitrag von: Gigafix am 05 März 2017, 08:41:06
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
Titel: Antw:Modul 96_SIP
Beitrag von: DerTom am 05 März 2017, 11:20:39
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...
Titel: Antw:Modul 96_SIP
Beitrag von: franky08 am 05 März 2017, 12:01:11
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 05 März 2017, 13:08:01
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 ! 
Titel: Antw:Modul 96_SIP
Beitrag von: franky08 am 05 März 2017, 13:10:59
Alles klar, dachte es bezieht sich nur auf das klingeln.  :)

VG
Frank
Titel: Antw:Modul 96_SIP
Beitrag von: frank am 07 März 2017, 10:55:59
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)
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 07 März 2017, 13:09:21
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.
Titel: Antw:Modul 96_SIP
Beitrag von: MadMax am 07 März 2017, 19:23:39
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 08 März 2017, 11:08:49
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.
Titel: Antw:Modul 96_SIP
Beitrag von: MadMax am 08 März 2017, 18:16:42
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
Titel: Antw:Modul 96_SIP
Beitrag von: Heuberg am 10 März 2017, 22:18:50
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 11 März 2017, 07:33:49
na klar , Seite 5 erster Beitrag #60  -> https://forum.fhem.de/index.php/topic,67443.msg593547.html#msg593547
= alte Net::Sip Version
Titel: Antw:Modul 96_SIP
Beitrag von: Heuberg am 11 März 2017, 08:16:45
@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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 11 März 2017, 08:20:24
die 0.808 solle OK sein , siehe Seite 8 # 119 -> https://forum.fhem.de/index.php/topic,67443.msg598836.html#msg598836
Titel: Antw:Modul 96_SIP
Beitrag von: Heuberg am 11 März 2017, 17:07:55
@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
Titel: Antw:Modul 96_SIP
Beitrag von: Medel am 12 März 2017, 10:32:35
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 12 März 2017, 10:44:23
@Medel: Tritt die Meldung nach einem save config und shutdown restart immer noch auf?
Titel: Antw:Modul 96_SIP
Beitrag von: Medel am 12 März 2017, 12:21:17
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 12 März 2017, 17:38:04
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. 
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 12 März 2017, 19:55:56
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
Titel: Antw:Modul 96_SIP
Beitrag von: punker am 13 März 2017, 12:38:05
Habs mal schnell mit sip call getestet und funzt perfekt!
Handynummer wird angerufen und Text wird ohne verzögerung gesprochen!
Titel: Antw:Modul 96_SIP
Beitrag 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.
Titel: Antw:Modul 96_SIP
Beitrag von: Heuberg am 15 März 2017, 20:34:41
Hallo Wzut,
ja, gerade beim Brötchenverdienen ;-).
Morgen Abend wird getestet.
Viele Grüße
Rainer
Titel: Antw:Modul 96_SIP
Beitrag von: det. am 15 März 2017, 21:04:01
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 16 März 2017, 07:37:15
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 
Titel: Antw:Modul 96_SIP
Beitrag von: Gisbert am 16 März 2017, 09:35:38
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 16 März 2017, 10:51:43
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 16 März 2017, 17:45:37
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 :-)
Titel: Antw:Modul 96_SIP
Beitrag von: JoWiemann am 16 März 2017, 21:18:09
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 17 März 2017, 07:46:26
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
Titel: Antw:Modul 96_SIP
Beitrag von: DerTom am 17 März 2017, 09:12:39
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...
Titel: Antw:Modul 96_SIP
Beitrag von: JoWiemann am 17 März 2017, 10:06:42
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....

Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 17 März 2017, 10:24:37
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+$/;
Titel: Antw:Modul 96_SIP
Beitrag von: JoWiemann am 17 März 2017, 10:42:12
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 17 März 2017, 10:58:34
@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.
Titel: Antw:Modul 96_SIP
Beitrag von: JoWiemann am 17 März 2017, 11:37:58
Danke für den Hinweis und erledigt.

Grüße Jörg
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 17 März 2017, 12:08:04
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
   
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 17 März 2017, 17:53:13
@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?

Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 17 März 2017, 20:58:38
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. 
Titel: Antw:Modul 96_SIP
Beitrag von: det. am 17 März 2017, 21:56:38
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 ???
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 18 März 2017, 09:07:17
@det, danke für die Info. SIP_watchdog_t2s ist falsch es muss SIP_watchdog_T2S sein. Werde ich gleich fixen
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 18 März 2017, 09:37:24
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:

Mit dem Ansatz ließe sich vielleicht die CPU-Auslastung reduzieren.

Oder man nimmt die Sub komplett auseinander und schreibt eine performantere Fassung.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 18 März 2017, 09:41:42
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???
Titel: Antw:Modul 96_SIP
Beitrag von: JoWiemann am 18 März 2017, 13:17:49
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 19 März 2017, 08:44:49
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 19 März 2017, 09:35:16
_dtmf_xtc_audio: offenbar kann man (lt.DTMF.pod) die audio-Erkennung ausschalten ... es fehlt aber wieder mal an passenden Beispielen
Titel: Antw:Modul 96_SIP
Beitrag von: JoWiemann am 19 März 2017, 09:37:47
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 19 März 2017, 11:15:47
_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.
Titel: Antw:Modul 96_SIP
Beitrag von: Atze am 19 März 2017, 15:08:52
@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?
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 19 März 2017, 15:57:14
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 19 März 2017, 15:59:26
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 19 März 2017, 18:50:46
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.   
Titel: Antw:Modul 96_SIP
Beitrag von: JoWiemann am 19 März 2017, 18:57:48
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  :)
Titel: Antw:Modul 96_SIP
Beitrag von: MadMax am 20 März 2017, 17:35:25
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
Titel: Modul 96_SIP Auflegen / Hangup
Beitrag von: Laserhelge am 20 März 2017, 18:33:19
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 20 März 2017, 19:39:30
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 ....
Titel: Antw:Modul 96_SIP
Beitrag von: MadMax am 21 März 2017, 06:19:49
@Wutz, genau das meine ich, also etwa 1s sleep
Titel: Antw:Modul 96_SIP
Beitrag von: tpm88 am 21 März 2017, 15:52:00
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 21 März 2017, 16:02:11
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Olly am 21 März 2017, 21:32:14
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 21 März 2017, 22:00:13
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Olly am 21 März 2017, 22:55:53
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
Titel: Antw:Modul 96_SIP
Beitrag von: Heuberg am 21 März 2017, 23:19:31
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

Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 22 März 2017, 06:58:04
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 :(
Titel: Ruf abweisen
Beitrag von: knodono am 22 März 2017, 09:02:09
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
Titel: Antw:Modul 96_SIP
Beitrag von: JoWiemann am 22 März 2017, 09:03:13
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 22 März 2017, 09:54:30
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



Titel: Antw:Modul 96_SIP
Beitrag von: knodono am 22 März 2017, 10:20:32
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
Titel: Antw:Modul 96_SIP
Beitrag von: Olly am 22 März 2017, 13:27:40


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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 22 März 2017, 14:44:52
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.
Titel: Antw:Modul 96_SIP
Beitrag von: knodono am 22 März 2017, 15:48:24
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 22 März 2017, 17:34:13
Versuch mal bei sip_registrar fritz.box die IP-Adresse der FritzBox einzutragen und den sip_port 5070 zu nehmen.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 22 März 2017, 17:39:41
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
Titel: Antw:Modul 96_SIP
Beitrag von: knodono am 22 März 2017, 17:54:00
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 22 März 2017, 19:09:43
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 ...
Titel: Antw:Modul 96_SIP
Beitrag von: Olly am 22 März 2017, 21:03:47
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 23 März 2017, 07:16:09
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Olly am 23 März 2017, 09:22:30


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
Titel: Antw:Ruf abweisen
Beitrag von: Wzut am 24 März 2017, 09:21:13
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.
Titel: Antw:Modul 96_SIP
Beitrag von: franky08 am 24 März 2017, 09:49:35
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
Titel: Antw:Ruf abweisen
Beitrag von: knodono am 24 März 2017, 09:55:10
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 24 März 2017, 20:35:35
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.
Titel: Antw:Modul 96_SIP
Beitrag von: knodono am 25 März 2017, 16:25:39
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 25 März 2017, 17:55:26
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.
Titel: Antw:Modul 96_SIP
Beitrag von: knodono am 25 März 2017, 18:41:41
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.
Titel: Antw:Modul 96_SIP
Beitrag 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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 25 März 2017, 23:11:05
Schon die 701, 486 oder 487 probiert?
Titel: Antw:Modul 96_SIP
Beitrag von: knodono am 26 März 2017, 08:06:57
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|
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 26 März 2017, 08:43:09
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.
Titel: Antw:Modul 96_SIP
Beitrag von: knodono am 26 März 2017, 09:57:19
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 26 März 2017, 10:49:31
tja,

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 ...

Titel: Antw:Modul 96_SIP
Beitrag von: plin am 26 März 2017, 15:28:24
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 26 März 2017, 17:07:29
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 ?
Titel: Antw:Modul 96_SIP
Beitrag von: knodono am 26 März 2017, 18:22:35
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Prostetnik am 29 März 2017, 09:33:28
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 29 März 2017, 11:56:38
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.
Titel: Antw:Modul 96_SIP
Beitrag 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. 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...
Titel: Antw:Modul 96_SIP
Beitrag von: frank am 29 März 2017, 14:09:13
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 29 März 2017, 14:32:28
@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
Titel: Antw:Modul 96_SIP
Beitrag von: Laffer72 am 29 März 2017, 15:04:46
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 29 März 2017, 15:13:37
THX Reinhard für die Info. @ plin, sollten wir unbedingt im Wiki festhalten
Titel: Antw:Modul 96_SIP
Beitrag von: Prostetnik am 29 März 2017, 19:05:43
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Prostetnik am 29 März 2017, 19:41:39
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... ;-)
Titel: Modul 96_SIP
Beitrag von: RaspiLED am 29 März 2017, 20:01:29
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, ...
Titel: Antw:Modul 96_SIP
Beitrag 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)
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 29 März 2017, 21:24:40
@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
Titel: Antw:Modul 96_SIP
Beitrag von: fiedel am 29 März 2017, 22:20:16
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 29 März 2017, 22:26:57
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Prostetnik am 29 März 2017, 22:46:40
@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...
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 30 März 2017, 10:49:13
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. 
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 30 März 2017, 12:38:30
>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 ...)
Titel: Antw:Modul 96_SIP
Beitrag von: Martin-72 am 31 März 2017, 12:37:40
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
Titel: Antw:Modul 96_SIP
Beitrag 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.
Das hässliche Geräusch ist gewollt bis du dir etwas nettes aussuchst :)   
Titel: Antw:Modul 96_SIP
Beitrag von: Martin-72 am 31 März 2017, 14:20:32
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...
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 31 März 2017, 14:40:50
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.



Titel: Antw:Modul 96_SIP
Beitrag von: Prostetnik am 31 März 2017, 15:03:00
Kurze Rückmeldung: Gerade mal mit der neuen version probiert. Audiodelay geht jetzt, die Wiederholung bei t2s aber leider nicht.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 31 März 2017, 15:23:06
Zitat von: Prostetnik am 31 März 2017, 15:03:00
die Wiederholung bei t2s aber leider nicht.
Log mit verbose 5 ?
Titel: Antw:Modul 96_SIP
Beitrag von: Prostetnik am 31 März 2017, 16:29:00
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 31 März 2017, 16:43:43
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 :(
Titel: Antw:Modul 96_SIP
Beitrag von: Prostetnik am 31 März 2017, 17:14:58
Ist mir auch schon aufgefallen... ;-)
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 01 April 2017, 14:29:07
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
Titel: Antw:Modul 96_SIP
Beitrag von: Prostetnik am 01 April 2017, 16:02:32
Cool! :)
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 02 April 2017, 18:02:09
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Heuberg am 02 April 2017, 20:14:55
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 03 April 2017, 07:19:06
Nein das siehst du schon richtig
Teste doch bitte nochmal mit der V1.52 (die sollte ja in knapp einer halben Stunde ausgeliefert werden)
Titel: Antw:Modul 96_SIP
Beitrag von: Heuberg am 03 April 2017, 22:04:46
Hallo Wzut,

ein Traum, das Problem ist beseitigt  ;D.

Danke und viele Grüße
Rainer
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 04 April 2017, 09:31:38
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Heuberg am 04 April 2017, 11:39:49
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 05 April 2017, 09:24:27
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"     

Titel: Antw:Modul 96_SIP
Beitrag von: JensS am 15 April 2017, 18:42:57
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 16 April 2017, 10:48:18
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.
Titel: Antw:Modul 96_SIP
Beitrag von: JensS am 16 April 2017, 18:16:01
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 :)
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 22 April 2017, 08:57:01
Stichwort Werbeanrufe

Im 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

:)

Titel: Antw:Modul 96_SIP
Beitrag von: inesa394 am 06 Mai 2017, 20:45:44
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 07 Mai 2017, 09:26:59
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 
Titel: Antw:Modul 96_SIP
Beitrag von: inesa394 am 07 Mai 2017, 14:30:38
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 07 Mai 2017, 19:05:18
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.
Titel: Antw:Modul 96_SIP
Beitrag von: inesa394 am 07 Mai 2017, 21:16:16
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 08 Mai 2017, 09:43:31
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.
Titel: Antw:Modul 96_SIP
Beitrag von: inesa394 am 08 Mai 2017, 13:37:35
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 08 Mai 2017, 16:12:48
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.
Titel: Antw:Modul 96_SIP
Beitrag von: inesa394 am 09 Mai 2017, 15:19:20
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. :)
Titel: Antw:Modul 96_SIP
Beitrag von: matschig4711 am 25 Mai 2017, 17:52:17
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 25 Mai 2017, 18:56:15
schau mal ins Wiki rein: https://wiki.fhem.de/wiki/SIP-Client#Anwendungsbeispiele
Titel: Antw:Modul 96_SIP
Beitrag von: matschig4711 am 25 Mai 2017, 21:23:49
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 26 Mai 2017, 07:37:36
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.

Titel: Antw:Modul 96_SIP
Beitrag von: matschig4711 am 26 Mai 2017, 07:56:48
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.

Titel: Antw:Modul 96_SIP
Beitrag von: Heuberg am 26 Mai 2017, 08:25:08
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 26 Mai 2017, 11:08:15
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. 
Titel: Antw:Modul 96_SIP
Beitrag von: Heuberg am 28 Mai 2017, 08:11:48
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 28 Mai 2017, 18:48:46
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 :(
Titel: Antw:Modul 96_SIP
Beitrag 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?
Titel: Antw:Modul 96_SIP
Beitrag 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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 10 Juni 2017, 17:57:09
@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.


Titel: Modul 96_SIP
Beitrag von: Tomk am 10 Juni 2017, 20:16:51
@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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 11 Juni 2017, 08:39:13
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.
Titel: Modul 96_SIP
Beitrag von: Tomk am 11 Juni 2017, 09:11:49
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?
Titel: Antw:Modul 96_SIP
Beitrag von: F.R. am 11 Juni 2017, 20:38:31
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?
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 11 Juni 2017, 21:12:33
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.
Titel: Antw:Modul 96_SIP
Beitrag von: F.R. am 11 Juni 2017, 21:28:48
Puh, das klingt kompliziert. Hast du eine Idee wie ich das umsetzen könnte?
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 11 Juni 2017, 21:49:42
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 12 Juni 2017, 19:40:59
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.
Titel: Antw:Modul 96_SIP
Beitrag von: F.R. am 12 Juni 2017, 20:25:07
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!
Titel: Antw:Modul 96_SIP
Beitrag von: Tomk am 16 Juni 2017, 09:11:53
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
Titel: Antw:Modul 96_SIP
Beitrag 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

Raspi3 mit Fritzbox 7490 und Gigaset Dect
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 24 Juni 2017, 07:53:05
ein Log Auszug mit verbose 5 für set Klingel_Telefon **610 1 könnte da eventuell etwas Licht ins Dunkel bringen :)
Titel: Antw:Modul 96_SIP
Beitrag von: RitterSport am 24 Juni 2017, 13:43:55
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
Titel: Antw:Modul 96_SIP
Beitrag von: drdownload am 24 Juni 2017, 14:56:41
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 24 Juni 2017, 15:37:28
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 ?
Titel: Antw:Modul 96_SIP
Beitrag von: RitterSport am 24 Juni 2017, 19:00:34
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....
Titel: Antw:Modul 96_SIP
Beitrag von: juergen012 am 25 Juni 2017, 16:18:47
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 25 Juni 2017, 18:56:54
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

Titel: Antw:Modul 96_SIP
Beitrag von: Lichti am 27 Juni 2017, 20:39:54
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 27 Juni 2017, 21:00:50
Was sagt ein
cpan install Net::DNS
?
Titel: Antw:Modul 96_SIP
Beitrag 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
Titel: Antw:Modul 96_SIP
Beitrag von: Tomk am 28 Juni 2017, 05:52:42
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Lichti am 28 Juni 2017, 10:45:11
@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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 29 Juni 2017, 17:56:14
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 :-)
Titel: Antw:Modul 96_SIP
Beitrag von: Tomk am 14 Juli 2017, 20:27:26
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 14 Juli 2017, 21:24:17
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Tomk am 15 Juli 2017, 06:29:36
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 15 Juli 2017, 08:51:46
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.
Titel: Antw:Modul 96_SIP
Beitrag von: teitesmars am 31 Juli 2017, 13:54:12
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!
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 31 Juli 2017, 14:38:37
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
Titel: Antw:Modul 96_SIP
Beitrag von: teitesmars am 31 Juli 2017, 16:14:08
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 ,
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 31 Juli 2017, 17:32:18
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 31 Juli 2017, 20:11:51
Zitat von: Wzut am 31 Juli 2017, 17:32:18
Edit : Das Wiki war schon auf dem aktuellen Stand :
Puh ...  ::)
Titel: Antw:Modul 96_SIP
Beitrag von: fiedel am 11 August 2017, 18:08:50
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 11 August 2017, 19:53:08
:) :) 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. 
Titel: Antw:Modul 96_SIP
Beitrag von: sweetie-pie am 22 August 2017, 23:32:12
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 23 August 2017, 06:56:19
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
Titel: Antw:Modul 96_SIP
Beitrag von: sbiermann am 23 August 2017, 18:26:45
@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.
Titel: Antw:Modul 96_SIP
Beitrag von: sweetie-pie am 23 August 2017, 23:17:43
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




Titel: Antw:Modul 96_SIP
Beitrag von: plin am 25 August 2017, 17:58:24
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 25 August 2017, 19:20:48
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.
Titel: Antw:Modul 96_SIP
Beitrag von: juliar am 26 August 2017, 08:52:28
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 26 August 2017, 09:20:09
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
Titel: Antw:Modul 96_SIP
Beitrag von: juliar am 26 August 2017, 09:28:54
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 26 August 2017, 13:36:07
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.
Titel: Antw:Modul 96_SIP
Beitrag von: juliar am 26 August 2017, 22:35:58
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 27 August 2017, 08:55:16
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)

Titel: Antw:Modul 96_SIP
Beitrag von: juliar am 27 August 2017, 21:39:28
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
Titel: Antw:Modul 96_SIP
Beitrag von: knodono am 20 September 2017, 09:05:20
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 20 September 2017, 09:28:54
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.
Titel: Antw:Modul 96_SIP
Beitrag von: knodono am 20 September 2017, 11:09:37
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.
Titel: Antw:Modul 96_SIP
Beitrag 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
Titel: Antw:Modul 96_SIP
Beitrag von: RaspiCOC am 22 September 2017, 15:23:35
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?
Titel: Antw:Modul 96_SIP
Beitrag 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");}
Titel: Antw:Modul 96_SIP
Beitrag von: knodono am 22 September 2017, 17:37:51
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.
Titel: Antw:Modul 96_SIP
Beitrag von: RaspiCOC am 22 September 2017, 21:02:00
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...  :'(
Titel: Antw:Modul 96_SIP
Beitrag von: frank am 10 Oktober 2017, 13:05:52
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 10 Oktober 2017, 15:28:46
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. 
Titel: Antw:Modul 96_SIP
Beitrag von: frank am 10 Oktober 2017, 22:39:33
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 11 Oktober 2017, 09:48:39
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"  :)       
Titel: Antw:Modul 96_SIP
Beitrag 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.

Edit : Anhang gelöscht , diese Version ist jetzt via update zu beziehen
Titel: Antw:Modul 96_SIP
Beitrag von: frank am 12 Oktober 2017, 17:04:44
danke, aber ich kann leider erst kommende woche testen.

gruss frank
Titel: Antw:Modul 96_SIP
Beitrag von: moeweflieg am 17 Oktober 2017, 21:37:34
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 18 Oktober 2017, 07:11:51
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......
Titel: Antw:Modul 96_SIP
Beitrag von: frank am 19 Oktober 2017, 13:57:38
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 19 Oktober 2017, 16:01:13
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
Titel: Antw:Modul 96_SIP
Beitrag von: moeweflieg am 19 Oktober 2017, 21:43:16
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
Titel: Antw:Modul 96_SIP
Beitrag von: Mikka am 19 Oktober 2017, 21:43:49
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 20 Oktober 2017, 08:58:58
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 20 Oktober 2017, 09:13:43
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.
Titel: Antw:Modul 96_SIP
Beitrag von: moeweflieg am 21 Oktober 2017, 08:48:31
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
Titel: Antw:Modul 96_SIP
Beitrag von: moeweflieg am 21 Oktober 2017, 09:14:23
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
Titel: Antw:Modul 96_SIP
Beitrag von: Mikka am 21 Oktober 2017, 11:00:02
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 21 Oktober 2017, 13:47:14
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Mikka am 21 Oktober 2017, 14:57:02
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 21 Oktober 2017, 15:54:12
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 ....
Titel: Antw:Modul 96_SIP
Beitrag von: Mikka am 22 Oktober 2017, 09:42:36
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 22 Oktober 2017, 09:59:30
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?
Titel: Antw:Modul 96_SIP
Beitrag von: moeweflieg am 22 Oktober 2017, 15:29:50
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 22 Oktober 2017, 19:31:44
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 
Titel: Antw:Modul 96_SIP
Beitrag von: Tomk am 22 Oktober 2017, 20:04:01
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
Titel: Antw:Modul 96_SIP
Beitrag von: moeweflieg am 23 Oktober 2017, 00:11:52
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

Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 23 Oktober 2017, 10:37:33
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.
Titel: Antw:Modul 96_SIP
Beitrag von: frank am 26 Oktober 2017, 22:24:35
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 27 Oktober 2017, 11:11:57
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. 
Titel: Antw:Modul 96_SIP
Beitrag von: frank am 27 Oktober 2017, 12:56:51
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 27 Oktober 2017, 13:18:22
wenns scheeee macht ...  :P dann ersetze ich das yes durch die PID
Titel: Antw:Modul 96_SIP
Beitrag von: eppi am 29 Oktober 2017, 11:23:17
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 29 Oktober 2017, 13:45:31
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.   

Titel: Antw:Modul 96_SIP
Beitrag von: eppi am 29 Oktober 2017, 18:22:03
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 29 Oktober 2017, 18:58:39
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.
Titel: Antw:Modul 96_SIP
Beitrag von: eppi am 30 Oktober 2017, 07:17:58
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
Titel: Antw:Modul 96_SIP
Beitrag 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
Titel: Antw:Modul 96_SIP
Beitrag von: frank am 30 Oktober 2017, 16:26:49
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.
Titel: Antw:Modul 96_SIP
Beitrag von: sojos am 02 November 2017, 21:40:42
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.
Titel: Antw:Modul 96_SIP
Beitrag 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 )

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.   
Titel: Antw:Modul 96_SIP
Beitrag von: sojos am 03 November 2017, 18:37:16
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 03 November 2017, 19:45:01
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.
Titel: modul erkennt auflegen nicht
Beitrag von: geiercasi am 04 November 2017, 15:45:39
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
Titel: Antw:Modul 96_SIP
Beitrag 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 ?
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 04 November 2017, 18:32:42
Je nachdem was passieren soll ist eine Kombination aus sip_filter/sip_blocking evtl. zielführend.
Titel: Antw:Modul 96_SIP
Beitrag von: Muschelpuster am 05 November 2017, 10:33:47
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
Titel: Antw:Modul 96_SIP
Beitrag von: geiercasi am 05 November 2017, 11:38:32
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 :)
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 05 November 2017, 13:06:43
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 05 November 2017, 16:16:45
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.
Titel: Antw:Modul 96_SIP
Beitrag von: sojos am 05 November 2017, 16:48:11
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.


Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 05 November 2017, 17:09:25
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 :)

Titel: Antw:Modul 96_SIP
Beitrag von: Muschelpuster am 05 November 2017, 18:02:10
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 05 November 2017, 18:38:47
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 06 November 2017, 21:00:54
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.
Titel: Antw:Modul 96_SIP
Beitrag 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.
Titel: Antw:Modul 96_SIP
Beitrag 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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 07 November 2017, 18:50:45
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?
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 07 November 2017, 18:53:32
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).
Titel: Antw:Modul 96_SIP
Beitrag von: eppi am 07 November 2017, 18:56:54
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...
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 07 November 2017, 19:06:12
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);

Titel: Antw:Modul 96_SIP
Beitrag von: heinerwm am 14 November 2017, 19:16:54
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

Titel: Antw:Modul 96_SIP
Beitrag von: plin am 14 November 2017, 20:46:15
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
Titel: Antw:Modul 96_SIP
Beitrag von: Horst_T am 15 November 2017, 11:38:29
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
Titel: Antw:Modul 96_SIP
Beitrag 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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 15 November 2017, 17:19:06
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 15 November 2017, 17:20:31
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
Titel: Antw:Modul 96_SIP
Beitrag von: heinerwm am 15 November 2017, 17:32:07
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
Titel: Antw:Modul 96_SIP
Beitrag von: Horst_T am 15 November 2017, 17:34:20
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
Titel: Antw:Modul 96_SIP
Beitrag von: Muschelpuster am 15 November 2017, 18:50:48
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
Titel: Antw:Modul 96_SIP
Beitrag von: heinerwm am 15 November 2017, 19:37:40
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 15 November 2017, 20:13:14
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
Titel: Antw:Modul 96_SIP
Beitrag von: Muschelpuster am 15 November 2017, 21:55:33
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
Titel: Antw:Modul 96_SIP
Beitrag von: heinerwm am 15 November 2017, 22:27:26
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
Titel: Antw:Modul 96_SIP
Beitrag von: Muschelpuster am 16 November 2017, 06:57:47
Moin Heiner,

Welche Version hat Deine Fritte?

neugierige Grüße
Niels
Titel: Antw:Modul 96_SIP
Beitrag von: heinerwm am 16 November 2017, 09:00:24
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
Titel: Antw:Modul 96_SIP
Beitrag von: Muschelpuster am 16 November 2017, 13:50:36
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 16 November 2017, 17:20:51
und meine Fritte hat Version 6.92
Titel: Antw:Modul 96_SIP
Beitrag von: MadMax-FHEM am 17 November 2017, 00:30:16
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
Titel: Antw:Modul 96_SIP
Beitrag 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.

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

Titel: Antw:Modul 96_SIP
Beitrag von: MadMax-FHEM am 17 November 2017, 19:57:03
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
Titel: Antw:Modul 96_SIP
Beitrag von: Muschelpuster am 19 November 2017, 14:58:13
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 19 November 2017, 15:09:14
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
Titel: Antw:Modul 96_SIP
Beitrag 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 !
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 19 November 2017, 18:16:41
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 :-)
Titel: Antw:Modul 96_SIP
Beitrag von: MadMax-FHEM am 19 November 2017, 18:37:29
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 20 November 2017, 17:24:33
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
Titel: Antw:Modul 96_SIP
Beitrag von: MadMax-FHEM am 20 November 2017, 20:35:26
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
Titel: Antw:Modul 96_SIP
Beitrag von: Elektrolurch am 25 November 2017, 12:37:37
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
 
Titel: Antw:Modul 96_SIP
Beitrag von: Rewe2000 am 26 November 2017, 17:04:54
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 26 November 2017, 17:44:37
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
Titel: Antw:Modul 96_SIP
Beitrag von: Rewe2000 am 26 November 2017, 18:05:59
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 26 November 2017, 18:37:48
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
Titel: Antw:Modul 96_SIP
Beitrag von: Rewe2000 am 26 November 2017, 19:09:40
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 26 November 2017, 20:04:28
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
Titel: Antw:Modul 96_SIP
Beitrag von: Rewe2000 am 26 November 2017, 20:51:35
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 27 November 2017, 17:51:42
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 ?
Titel: Antw:Modul 96_SIP
Beitrag von: Rewe2000 am 27 November 2017, 18:45:57
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 27 November 2017, 19:37:07
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
Titel: Antw:Modul 96_SIP
Beitrag von: Rewe2000 am 27 November 2017, 19:55:50
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 27 November 2017, 20:02:34
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
Titel: Antw:Modul 96_SIP
Beitrag von: Rewe2000 am 27 November 2017, 21:34:40
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
Titel: Antw:Modul 96_SIP
Beitrag von: Muschelpuster am 28 November 2017, 06:44:12
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 44446Wenn nichts kommt, dann poste auch gerne mal die Ausgabe von ss ohne das grep.

abgefragende Grüße
Niels
Titel: Antw:Modul 96_SIP
Beitrag von: heinerwm am 28 November 2017, 15:38:01
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
Titel: Antw:Modul 96_SIP
Beitrag von: Rewe2000 am 28 November 2017, 18:06:58
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
Titel: Antw:Modul 96_SIP
Beitrag von: MadMax-FHEM am 28 November 2017, 19:38:21
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
Titel: Antw:Modul 96_SIP
Beitrag von: Rewe2000 am 28 November 2017, 20:44:14
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 28 November 2017, 20:56:11
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
Titel: Antw:Modul 96_SIP
Beitrag von: Rewe2000 am 28 November 2017, 22:38:05
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
Titel: Antw:Modul 96_SIP
Beitrag von: MadMax-FHEM am 29 November 2017, 00:02:49
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
Titel: Antw:Modul 96_SIP
Beitrag von: Rewe2000 am 29 November 2017, 18:17:41
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 30 November 2017, 08:11:30
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.
Titel: Antw:Modul 96_SIP
Beitrag von: MadMax-FHEM am 30 November 2017, 10:40:49
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 30 November 2017, 16:16:01
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.
Titel: Antw:Modul 96_SIP
Beitrag von: MadMax-FHEM am 30 November 2017, 17:23:36
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 30 November 2017, 20:44:45
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Rewe2000 am 30 November 2017, 23:01:17
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 01 Dezember 2017, 11:20:02
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. 
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 01 Dezember 2017, 19:39:27
@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.
Titel: Antw:Modul 96_SIP
Beitrag von: Rewe2000 am 01 Dezember 2017, 21:04:04
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
Titel: Antw:Modul 96_SIP
Beitrag von: Rewe2000 am 01 Dezember 2017, 21:33:20
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 01 Dezember 2017, 21:57:23
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 02 Dezember 2017, 09:29:10
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
Titel: Antw:Modul 96_SIP
Beitrag von: Rewe2000 am 02 Dezember 2017, 11:49:46
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 02 Dezember 2017, 14:02:24
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 02 Dezember 2017, 14:57:58
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Rewe2000 am 02 Dezember 2017, 20:21:44
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

Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 03 Dezember 2017, 08:47:03
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.




Titel: Antw:Modul 96_SIP
Beitrag von: plin am 03 Dezember 2017, 09:15:51
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Rewe2000 am 03 Dezember 2017, 11:09:10
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 03 Dezember 2017, 11:37:02
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   
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 03 Dezember 2017, 13:25:14
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 03 Dezember 2017, 14:58:11
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

Titel: Antw:Modul 96_SIP
Beitrag von: plin am 03 Dezember 2017, 17:47:19
so geht's natürlich auch  8)
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 03 Dezember 2017, 18:26:53
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.


Titel: Antw:Modul 96_SIP
Beitrag von: plin am 03 Dezember 2017, 19:11:17
Das erste schnelle Feedback (vor dem Abendessen):
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 03 Dezember 2017, 19:49:11
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 ?
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 03 Dezember 2017, 19:53:51
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 03 Dezember 2017, 20:04:37
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 04 Dezember 2017, 12:36:39
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 04 Dezember 2017, 17:53:15
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.


Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 04 Dezember 2017, 18:09:42
hmmm, jetzt bin ich platt  :( und habe auch keine logische Erklärung. Aber anyway werde ich natürlich testen
Titel: Antw:Modul 96_SIP
Beitrag von: Rewe2000 am 04 Dezember 2017, 18:21:50
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


Titel: Antw:Modul 96_SIP
Beitrag von: plin am 04 Dezember 2017, 18:22:40
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Rewe2000 am 04 Dezember 2017, 18:55:39
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 04 Dezember 2017, 19:30:12
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Rewe2000 am 04 Dezember 2017, 21:03:58
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 04 Dezember 2017, 21:45:53
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.
Titel: Antw:Modul 96_SIP
Beitrag 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.

minimalistische Grüße
Niels
Titel: Antw:Modul 96_SIP
Beitrag von: Muschelpuster am 04 Dezember 2017, 21:57:16
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 04 Dezember 2017, 22:18:07
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 ...
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 05 Dezember 2017, 07:46:32
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.   
Titel: Antw:Modul 96_SIP
Beitrag von: Muschelpuster am 05 Dezember 2017, 08:26:04
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
Titel: Antw:Modul 96_SIP
Beitrag von: heinerwm am 05 Dezember 2017, 10:39:05
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
Titel: Antw:Modul 96_SIP
Beitrag 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.
Titel: Antw:Modul 96_SIP
Beitrag von: heinerwm am 05 Dezember 2017, 16:41:19
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
Titel: Antw:Modul 96_SIP
Beitrag 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 ?
Titel: Antw:Modul 96_SIP
Beitrag von: heinerwm am 05 Dezember 2017, 17:32:18
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
Titel: Antw:Modul 96_SIP
Beitrag von: Elektrolurch am 06 Dezember 2017, 16:45:07
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
Titel: Antw:Modul 96_SIP
Beitrag von: Decki am 06 Dezember 2017, 16:49:00
Gleiches Problem bei mir.
Bei tts kommen nur Pieptöne. Welche samplingrate muss eingestellt werden für u-law Codec?
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 06 Dezember 2017, 16:50:24
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
Titel: Antw:Modul 96_SIP
Beitrag von: Rewe2000 am 06 Dezember 2017, 18:15:21
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
Titel: Antw:Modul 96_SIP
Beitrag von: Rewe2000 am 06 Dezember 2017, 19:54:43
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 06 Dezember 2017, 22:03:37
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 07 Dezember 2017, 07:01:09
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!
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 07 Dezember 2017, 07:45:23
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
Titel: Antw:Modul 96_SIP
Beitrag von: Elektrolurch am 07 Dezember 2017, 11:06:42
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 07 Dezember 2017, 11:27:47
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 ?
Titel: Antw:Modul 96_SIP
Beitrag von: Elektrolurch am 07 Dezember 2017, 11:40:45
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 07 Dezember 2017, 12:15:55
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> 
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 07 Dezember 2017, 20:11:54
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
Titel: Antw:Modul 96_SIP
Beitrag von: Rewe2000 am 07 Dezember 2017, 20:49:53
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 07 Dezember 2017, 21:54:17
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 08 Dezember 2017, 06:57:44
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)
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 08 Dezember 2017, 07:20:47
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 :)
Titel: Antw:Modul 96_SIP
Beitrag von: Rewe2000 am 08 Dezember 2017, 20:37:11
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
Titel: Antw:Modul 96_SIP
Beitrag von: Elektrolurch am 09 Dezember 2017, 11:15:29
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

 
Titel: Antw:Modul 96_SIP
Beitrag von: Rewe2000 am 09 Dezember 2017, 11:33:38
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
Titel: Antw:Modul 96_SIP
Beitrag von: Elektrolurch am 09 Dezember 2017, 11:49:29
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....
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 09 Dezember 2017, 12:57:55
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)
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 09 Dezember 2017, 14:50:55
@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: ,  ?
Titel: Antw:Modul 96_SIP
Beitrag von: Elektrolurch am 10 Dezember 2017, 10:41:11
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
   
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 10 Dezember 2017, 15:15:35
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
Titel: Antw:Modul 96_SIP
Beitrag von: Elektrolurch am 12 Dezember 2017, 14:00:57
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 12 Dezember 2017, 15:05:11
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
Titel: Antw:Modul 96_SIP
Beitrag von: Elektrolurch am 12 Dezember 2017, 16:19:44
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 12 Dezember 2017, 16:33:14
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. 
Titel: Antw:Modul 96_SIP
Beitrag von: Elektrolurch am 13 Dezember 2017, 11:35:17
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 13 Dezember 2017, 13:56:24
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)
Titel: Antw:Modul 96_SIP
Beitrag von: speedAmaster am 13 Dezember 2017, 18:32:36
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>
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 13 Dezember 2017, 19:31:23
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 13 Dezember 2017, 19:34:34
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.

Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 13 Dezember 2017, 21:41:24
klingt auch gut , die Arbeit muss man ja nur einmal machen.
Als Audioformat gleich u-law mono 8000 Hz auswählen ?
Titel: Antw:Modul 96_SIP
Beitrag von: speedAmaster am 14 Dezember 2017, 00:18:10
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
Titel: Antw:Modul 96_SIP
Beitrag von: Elektrolurch am 14 Dezember 2017, 11:52:29
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
Titel: Antw:Modul 96_SIP
Beitrag von: speedAmaster am 14 Dezember 2017, 12:56:36
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 14 Dezember 2017, 13:00:38
@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 ?
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 14 Dezember 2017, 13:03:39
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
Titel: Antw:Modul 96_SIP
Beitrag von: Elektrolurch am 14 Dezember 2017, 13:44:13
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 14 Dezember 2017, 14:14:03
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Elektrolurch am 14 Dezember 2017, 14:27:37
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 14 Dezember 2017, 14:49:00
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

 
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 16 Dezember 2017, 17:07:18
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 :) 
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 17 Dezember 2017, 10:09:25
Kurztest der 1.71:
listen_wfp -> geht
call -> geht
fetch -> geht
Titel: Antw:Modul 96_SIP
Beitrag von: Elektrolurch am 27 Dezember 2017, 10:22:48
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

Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 27 Dezember 2017, 17:26:05
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 ?
Titel: Antw:Modul 96_SIP
Beitrag von: Elektrolurch am 27 Dezember 2017, 17:47:54

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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 27 Dezember 2017, 18:56:03
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.   
Titel: Antw:Modul 96_SIP
Beitrag von: Elektrolurch am 28 Dezember 2017, 11:00:43
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 28 Dezember 2017, 11:50:45
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.   
Titel: Antw:Modul 96_SIP
Beitrag von: Elektrolurch am 28 Dezember 2017, 12:05:50
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


Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 28 Dezember 2017, 12:30:53
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 31 Dezember 2017, 14:53:30
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.

Titel: Antw:Modul 96_SIP
Beitrag von: Rewe2000 am 03 Januar 2018, 17:08:15
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 03 Januar 2018, 17:24:13
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Rewe2000 am 03 Januar 2018, 17:47:24
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
Titel: Antw:Modul 96_SIP
Beitrag von: wmeiners am 03 Januar 2018, 22:58:36
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 04 Januar 2018, 09:40:28
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.     
Titel: Antw:Modul 96_SIP
Beitrag von: Elektrolurch am 04 Januar 2018, 11:30:33
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 04 Januar 2018, 13:36:44
@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 ?   
Titel: Antw:Modul 96_SIP
Beitrag von: Elektrolurch am 04 Januar 2018, 18:42:01
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 05 Januar 2018, 07:41:02
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Elektrolurch am 05 Januar 2018, 11:19:45
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
Titel: Antw:Modul 96_SIP
Beitrag von: JoWiemann am 05 Januar 2018, 20:37:18
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 08 Januar 2018, 19:48:10
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 10 Januar 2018, 18:11:32
@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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 10 Januar 2018, 20:17:56
@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.
Titel: Antw:Modul 96_SIP
Beitrag von: prodigy7 am 14 Januar 2018, 16:18:38
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 14 Januar 2018, 17:34:58
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.
Titel: Antw:Modul 96_SIP
Beitrag von: prodigy7 am 14 Januar 2018, 19:32:53
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 14 Januar 2018, 20:12:25
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.
Titel: Antw:Modul 96_SIP
Beitrag von: prodigy7 am 14 Januar 2018, 20:23:11
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.
Titel: Antw:Modul 96_SIP
Beitrag von: JoWiemann am 14 Januar 2018, 20:56:44
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...

Titel: Antw:Modul 96_SIP
Beitrag von: prodigy7 am 14 Januar 2018, 21:27:07
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...
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 15 Januar 2018, 07:39:58
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.
 
Titel: Antw:Modul 96_SIP
Beitrag von: Tobias am 15 Januar 2018, 15:26:50
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 ;)
Titel: Antw:Modul 96_SIP
Beitrag von: prodigy7 am 29 Januar 2018, 08:34:33
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 29 Januar 2018, 17:55:16
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.
Titel: Antw:Modul 96_SIP
Beitrag von: prodigy7 am 29 Januar 2018, 22:08:36
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!
Titel: Antw:Modul 96_SIP
Beitrag von: anatius am 02 Februar 2018, 20:21:16
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 03 Februar 2018, 08:39:27
Ü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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 03 Februar 2018, 14:20:48
Ich glaube ich habe das Problem heute Morgen falsch verstanden um einen aktiven Call im Status ringing zu killen versuch mal set <name> reset
Titel: Antw:Modul 96_SIP
Beitrag von: justme1968 am 06 Februar 2018, 18:09:23
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?
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 06 Februar 2018, 18:24:28
@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.
Titel: Antw:Modul 96_SIP
Beitrag von: justme1968 am 06 Februar 2018, 18:37:27
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 07 Februar 2018, 07:05:26
@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
Titel: Antw:Modul 96_SIP
Beitrag von: justme1968 am 07 Februar 2018, 09:48:21
oh mann...

ich habe die letzte spalte mit dem klingelton aus irgend einem rund nicht gesehen. wunderbar! danke.
Titel: Antw:Modul 96_SIP
Beitrag von: anatius am 11 Februar 2018, 09:42:35
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 12 Februar 2018, 13:02:34
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 )
Titel: Antw:Modul 96_SIP
Beitrag von: Cyzicos am 14 Februar 2018, 19:20:49
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 14 Februar 2018, 19:31:07
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. 
Titel: Antw:Modul 96_SIP
Beitrag von: frank am 15 Februar 2018, 10:12:47
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.
Titel: Antw:Modul 96_SIP
Beitrag 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ß
Titel: Antw:Modul 96_SIP
Beitrag von: JoWiemann am 07 März 2018, 21:16:09
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
Titel: Antw:Modul 96_SIP
Beitrag von: Pusemukel am 07 März 2018, 21:43:25
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ß
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 08 März 2018, 07:29:13
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
Titel: Antw:Modul 96_SIP
Beitrag von: Pusemukel am 08 März 2018, 19:49:54
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ß
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 08 März 2018, 20:05:12
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).
Titel: Antw:Modul 96_SIP
Beitrag von: Pusemukel am 08 März 2018, 20:55:52
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ß

Titel: Antw:Modul 96_SIP
Beitrag von: plin am 08 März 2018, 22:17:31
Im attr sip_from fehlt das sip:
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 09 März 2018, 08:03:11
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 ....
Titel: Antw:Modul 96_SIP
Beitrag von: Pusemukel am 09 März 2018, 15:42:53
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
Titel: Antw:Modul 96_SIP
Beitrag von: adrian am 31 März 2018, 15:54:55
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
Titel: Antw:Modul 96_SIP
Beitrag von: frank am 31 März 2018, 15:58:46
du musst einfach mit events arbeiten und nicht mit zuständen. egal ob mit notify oder doif.
Titel: Antw:Modul 96_SIP
Beitrag von: adrian am 05 April 2018, 21:07:45
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.
Titel: Antw:Modul 96_SIP
Beitrag von: frank am 06 April 2018, 00:12:29
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 06 April 2018, 06:50:00
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 
Titel: Antw:Modul 96_SIP
Beitrag von: Andre0909 am 29 April 2018, 14:03:06
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
Titel: Antw:Modul 96_SIP
Beitrag 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")?
Titel: Antw:Modul 96_SIP
Beitrag von: Andre0909 am 29 April 2018, 14:19:46
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 :(
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 29 April 2018, 14:36:55
Set mal den sip_user auf Andre0909
Titel: Antw:Modul 96_SIP
Beitrag von: Andre0909 am 29 April 2018, 17:38:46
Zitat von: plin am 29 April 2018, 14:36:55
Set mal den sip_user auf Andre0909

JAP, das war es . Funzt! Vielen Dank
Titel: Antw:Modul 96_SIP
Beitrag von: Andre0909 am 29 April 2018, 21:10:46
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# ?
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 29 April 2018, 21:32:31
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.
Titel: Antw:Modul 96_SIP
Beitrag von: topfi am 10 Mai 2018, 14:24:22
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 ...
Titel: Antw:Modul 96_SIP
Beitrag 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.
Titel: Antw:Modul 96_SIP
Beitrag von: Elgardo am 16 Mai 2018, 23:36:09
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

   
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 17 Mai 2018, 07:39:18
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Elgardo am 17 Mai 2018, 22:33:07
PERFEKT!
Das war's. Bin von dem Modul und dem raschen Service begeistert.
Vielen Dank
Titel: Antw:Modul 96_SIP
Beitrag von: YellowBall am 23 Mai 2018, 06:46:40
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 23 Mai 2018, 06:53:47
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 !
Titel: Antw:Modul 96_SIP
Beitrag von: SELVE-Elektronik-Entwicklung am 29 Mai 2018, 18:13:14
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 29 Mai 2018, 18:28:26
wir brauchen den üblichen Input

Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 30 Mai 2018, 07:11:24
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. 
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 30 Mai 2018, 10:01:21
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Cruiser79 am 20 Juni 2018, 23:09:35
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

Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 21 Juni 2018, 17:54:03
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
Titel: Antw:Modul 96_SIP
Beitrag von: Cruiser79 am 21 Juni 2018, 22:02:25
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 22 Juni 2018, 08:18:25
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.
Titel: Antw:Modul 96_SIP
Beitrag 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
}
Titel: Antw:Modul 96_SIP
Beitrag von: habl am 23 Juni 2018, 07:21:30
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 23 Juni 2018, 08:21:57
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 23 Juni 2018, 09:01:03
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Cruiser79 am 24 Juni 2018, 14:16:25
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.
Titel: Antw:Modul 96_SIP
Beitrag 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).
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 24 Juni 2018, 16:48:41
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 ? 
Titel: Antw:Modul 96_SIP
Beitrag von: Cruiser79 am 24 Juni 2018, 20:36:58
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 25 Juni 2018, 13:50:45
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Cruiser79 am 30 Juni 2018, 13:06:23
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.
Titel: Antw:Modul 96_SIP
Beitrag 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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 02 Juli 2018, 19:23:20
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 ?
Titel: Antw:Modul 96_SIP
Beitrag von: thunder1902 am 03 Juli 2018, 10:26:24
@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??
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 03 Juli 2018, 11:14:40
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. 
Titel: Antw:Modul 96_SIP
Beitrag von: thunder1902 am 03 Juli 2018, 13:05:50
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...
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 03 Juli 2018, 18:14:53
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.
Titel: Antw:Modul 96_SIP
Beitrag von: thunder1902 am 03 Juli 2018, 20:21:01
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... :-/
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 03 Juli 2018, 20:45:45
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. 
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 04 Juli 2018, 18:58:24
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.
Titel: Antw:Modul 96_SIP
Beitrag von: pechnase am 09 Juli 2018, 13:48:18
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
Titel: Antw:Modul 96_SIP
Beitrag von: magichand am 09 Juli 2018, 14:18:09
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



Titel: Antw:Modul 96_SIP
Beitrag von: plin am 09 Juli 2018, 18:20:07
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 09 Juli 2018, 18:24:42
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)?
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 09 Juli 2018, 18:52:10
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.
Titel: Antw:Modul 96_SIP
Beitrag von: magichand am 10 Juli 2018, 12:48:10
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
Titel: Antw:Modul 96_SIP
Beitrag von: tpm88 am 10 Juli 2018, 13:42:57
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 10 Juli 2018, 15:37:23
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.
Titel: Antw:Modul 96_SIP
Beitrag von: tpm88 am 10 Juli 2018, 17:20:51
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 10 Juli 2018, 17:54:25
Ich schau mir das morgen oder am WE nochmal in Ruhe an und schneide ggf. zwischen : und @
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 10 Juli 2018, 20:31:26
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 ...
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 10 Juli 2018, 20:43:19
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."
Titel: Antw:Modul 96_SIP
Beitrag von: magichand am 12 Juli 2018, 14:31:43
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 12 Juli 2018, 19:00:50
@magichand: Wo hast Du Dein Docker-Image her? Dann kann ich versuchen das Problem nachzustellen.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 12 Juli 2018, 21:18:56
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 16 Juli 2018, 19:59:01
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.
Titel: Antw:Modul 96_SIP
Beitrag von: tpm88 am 16 Juli 2018, 23:01:25
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
Titel: Antw:Modul 96_SIP
Beitrag von: magichand am 16 Juli 2018, 23:40:24
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
Titel: Antw:Modul 96_SIP
Beitrag von: tpm88 am 19 Juli 2018, 23:10:01
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 20 Juli 2018, 07:11:49
@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
Titel: Antw:Modul 96_SIP
Beitrag von: tpm88 am 20 Juli 2018, 08:11:17
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 20 Juli 2018, 20:03:17
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
Titel: Antw:Modul 96_SIP
Beitrag von: tpm88 am 21 Juli 2018, 17:49:47
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
Titel: Antw:Modul 96_SIP
Beitrag 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 ..... :(
Titel: Antw:Modul 96_SIP
Beitrag von: tpm88 am 22 Juli 2018, 21:02:12
Auch V1.85 arbeitet in meinem Szenario listen_dtmf einwandfrei.
Titel: Antw:Modul 96_SIP
Beitrag von: det. am 30 Juli 2018, 20:25:34
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 31 Juli 2018, 06:05:30
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.
Titel: Antw:Modul 96_SIP
Beitrag von: det. am 31 Juli 2018, 09:13:49
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 fetchbei 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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 31 Juli 2018, 11:17:25
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.
Titel: Antw:Modul 96_SIP
Beitrag von: det. am 31 Juli 2018, 13:59:27
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 31 Juli 2018, 14:09:16
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.
Titel: Antw:Modul 96_SIP
Beitrag von: det. am 31 Juli 2018, 16:44:34
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....
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 31 Juli 2018, 21:07:01
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.
Titel: Antw:Modul 96_SIP
Beitrag von: det. am 31 Juli 2018, 23:29:19
Ok, ich teste mal und werde berichten...
Titel: Antw:Modul 96_SIP
Beitrag von: det. am 01 August 2018, 09:08:43
Danke, mit Version 1.91 ist wieder alles so wie gewohnt.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 01 August 2018, 09:47:40
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.
Titel: Antw:Modul 96_SIP
Beitrag von: rrr am 08 August 2018, 19:41:29
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 09 August 2018, 06:49:45
D.h. es betrifft nur den Listen Modus bei wfp und du verwendst die neuste Version V1.91 ?
Titel: Antw:Modul 96_SIP
Beitrag von: rrr am 09 August 2018, 14:07:17
Korrekt, es betrifft nur den Listen Modus bei wfp und ich verwende auch die Version 1.91.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 09 August 2018, 15:40:40
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.
Titel: Antw:Modul 96_SIP
Beitrag von: rrr am 09 August 2018, 18:15:25
Das wäre klasse, vielen Dank!
Titel: Antw:Modul 96_SIP
Beitrag von: stebar_ am 09 August 2018, 21:41:29
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Spartacus am 14 August 2018, 12:44:05
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 14 August 2018, 14:32:31
hatten wir hier schon X-fach , Net::SIP ist zu alt  -> https://forum.fhem.de/index.php/topic,80206.msg725755.html#msg725755
Titel: Antw:Modul 96_SIP
Beitrag von: magichand am 14 August 2018, 14:52:29
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
Titel: Antw:Modul 96_SIP
Beitrag von: Spartacus am 14 August 2018, 14:56:04
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 14 August 2018, 15:17:36
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Spartacus am 14 August 2018, 16:06:56
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 14 August 2018, 16:28:06
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
Titel: Antw:Modul 96_SIP
Beitrag 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?
Titel: Antw:Modul 96_SIP
Beitrag von: Spartacus am 14 August 2018, 16:53:59
@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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 14 August 2018, 17:46:04
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
Titel: Antw:Modul 96_SIP
Beitrag von: Spartacus am 14 August 2018, 18:33:17
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
Titel: Antw:Modul 96_SIP
Beitrag von: rrr am 14 August 2018, 19:22:15
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...
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 15 August 2018, 16:42:43
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";},
Titel: Antw:Modul 96_SIP
Beitrag von: olili am 17 August 2018, 15:03:06
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.



Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 17 August 2018, 19:32:23
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 ?
Titel: Antw:Modul 96_SIP
Beitrag von: rrr am 17 August 2018, 22:02:26
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.
Titel: Antw:Modul 96_SIP
Beitrag 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ß.

Titel: Antw:Modul 96_SIP
Beitrag von: Kilitom am 19 August 2018, 13:28:36
Hat schon mal jemand erfolgreich über einen externen SIP-Server "angerufen" (z.B. sipgate.de)? Ich versuch das grad - leider erfolglos ... :(
Titel: Antw:Modul 96_SIP
Beitrag 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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 19 August 2018, 15:21:07
und wieder einer ?  Eine Seite zurück ab meinem Posting #482 ... und gleiche die Frage : welche Version von Net::SIP ist installiert ?
Titel: Antw:Modul 96_SIP
Beitrag von: rrr am 19 August 2018, 17:50:02
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 19 August 2018, 18:55:53
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 ? 
Titel: Antw:Modul 96_SIP
Beitrag von: rrr am 19 August 2018, 20:25:58
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
Titel: Sipgate möglich?
Beitrag von: fstefan1960 am 20 August 2018, 14:44:02
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 20 August 2018, 15:42:03
Ein Thread reicht völlig -> https://forum.fhem.de/index.php/topic,90317.msg828721.html
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 20 August 2018, 20:29:09
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
Titel: Antw:Modul 96_SIP
Beitrag von: fiedel am 28 August 2018, 10:39:24
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!
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 29 August 2018, 07:08:20
hmm, sollte eigentlich gar nicht durchlaufen werden wenn das Attribut sip_ip gesetzt ist
Titel: Antw:Modul 96_SIP
Beitrag von: fiedel am 29 August 2018, 09:06:24
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 29 August 2018, 10:24:10
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
Titel: Antw:Modul 96_SIP
Beitrag von: fiedel am 29 August 2018, 12:40:50
THX4Fixing !  :)
Titel: Antw:Modul 96_SIP
Beitrag von: choetzu am 20 September 2018, 21:41:35
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
Titel: Antw:Modul 96_SIP
Beitrag 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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 21 September 2018, 07:53:06
Edit : die Swisscom Box sollte es auch können -> https://www.swisscom.ch/de/privatkunden/hilfe/festnetz/sip.html
Titel: Antw:Modul 96_SIP
Beitrag von: choetzu am 21 September 2018, 09:41:50
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...
Titel: Antw:Modul 96_SIP
Beitrag 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.
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.
Titel: Antw:Modul 96_SIP
Beitrag von: choetzu am 21 September 2018, 14:03:31
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 21 September 2018, 14:36:54
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.
Titel: Antw:Modul 96_SIP
Beitrag von: choetzu am 21 September 2018, 17:18:20
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 21 September 2018, 19:01:27
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)

Titel: Antw:Modul 96_SIP
Beitrag von: choetzu am 21 September 2018, 21:11:06
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? ;)
Titel: Antw:Modul 96_SIP
Beitrag 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
Titel: Antw:Modul 96_SIP
Beitrag von: Dia81 am 22 September 2018, 23:46:20
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 :)
Titel: Antw:Modul 96_SIP
Beitrag 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.
Titel: Antw:Modul 96_SIP
Beitrag von: Dia81 am 23 September 2018, 11:21:03
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 23 September 2018, 11:58:01
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#
Titel: Antw:Modul 96_SIP
Beitrag von: Dia81 am 23 September 2018, 12:21:03
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


Titel: Antw:Modul 96_SIP
Beitrag 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.
Titel: Antw:Modul 96_SIP
Beitrag von: Dia81 am 23 September 2018, 13:29:20
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-#
Titel: Antw:Modul 96_SIP
Beitrag von: choetzu am 23 September 2018, 22:42:22
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?
Titel: Antw:Modul 96_SIP
Beitrag 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. 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 :)
Titel: Antw:Modul 96_SIP
Beitrag von: choetzu am 24 September 2018, 15:02:19
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.. ;)
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 24 September 2018, 15:37:08
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.
Titel: Antw:Modul 96_SIP
Beitrag von: choetzu am 24 September 2018, 20:09:54
Ok, das hab ich kapiert ;) aber dann liegts eh an der unvollständigen Nummer. Das muss man dann ein set Sip reset machen..
Titel: Antw:Modul 96_SIP
Beitrag von: no_Legend am 26 September 2018, 07:53:25
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


Titel: Antw:Modul 96_SIP
Beitrag 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 ?
Titel: Antw:Modul 96_SIP
Beitrag 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.
Titel: Antw:Modul 96_SIP
Beitrag von: no_Legend am 27 September 2018, 08:51:46
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?
Titel: Antw:Modul 96_SIP
Beitrag 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.


Titel: Antw:Modul 96_SIP
Beitrag von: no_Legend am 27 September 2018, 10:47:38
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.
Titel: Antw:Modul 96_SIP
Beitrag von: no_Legend am 27 September 2018, 11:15:18
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 27 September 2018, 15:00:41
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


Titel: Antw:Modul 96_SIP
Beitrag von: plin am 27 September 2018, 17:09:18
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.
Titel: Antw:Modul 96_SIP
Beitrag von: mi.ke am 12 Oktober 2018, 11:51:07
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 12 Oktober 2018, 12:24:13
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 :)
Titel: Antw:Modul 96_SIP
Beitrag von: stera am 09 November 2018, 16:13:51
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 09 November 2018, 18:54:47
gleiche Antwort wie immer : verbose 5 Log anhängen !
Titel: Antw:Modul 96_SIP
Beitrag 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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 18 November 2018, 18:54:29
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.
Titel: Antw:Modul 96_SIP
Beitrag 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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 18 November 2018, 20:21:26
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.
Titel: Antw:Modul 96_SIP
Beitrag von: bennebartsch am 18 November 2018, 21:52:30
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?
Titel: Antw:Modul 96_SIP
Beitrag von: det. am 19 November 2018, 09:51:07
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 xxxx
Das 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,
Titel: Antw:Modul 96_SIP
Beitrag 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.

@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.
Titel: Antw:Modul 96_SIP
Beitrag von: det. am 19 November 2018, 13:54:13
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.
Titel: Antw:Modul 96_SIP
Beitrag von: bennebartsch am 19 November 2018, 15:04:30
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?
Titel: Antw:Modul 96_SIP
Beitrag 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 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
Titel: Antw:Modul 96_SIP
Beitrag von: bennebartsch am 19 November 2018, 15:49:19
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
Titel: Antw:Modul 96_SIP
Beitrag von: det. am 19 November 2018, 16:24:41
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 19 November 2018, 21:01:30
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.
Titel: Antw:Modul 96_SIP
Beitrag von: bennebartsch am 19 November 2018, 21:40:17
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
Titel: Antw:Modul 96_SIP
Beitrag von: The-Holgi am 14 Dezember 2018, 20:19:22
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 15 Dezember 2018, 08:21:19
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
Titel: Antw:Modul 96_SIP
Beitrag von: The-Holgi am 15 Dezember 2018, 08:41:56
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 15 Dezember 2018, 08:45:49
geh mal ein paar Seiten hier zurück bis Antwort #311 und folgende, da hatten wir das Thema Docker schon einmal.
Titel: Antw:Modul 96_SIP
Beitrag von: The-Holgi am 15 Dezember 2018, 12:30:11
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
Titel: Antw:Modul 96_SIP
Beitrag 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:


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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 20 Dezember 2018, 11:00:55
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.
Titel: Antw:Modul 96_SIP
Beitrag von: SirUli am 02 Januar 2019, 17:49:19
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 ;)

Titel: Antw:Modul 96_SIP
Beitrag von: UweUwe am 08 Januar 2019, 12:13:53
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


Titel: Antw:Modul 96_SIP
Beitrag von: UweUwe am 08 Januar 2019, 12:16:14
Die Änderung des IP Adresse hat nicht geändert, hab auch vor einem neuen Anruf set .. reset gemacht.
Titel: Antw:Modul 96_SIP
Beitrag von: UweUwe am 08 Januar 2019, 12:24:51
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








Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 08 Januar 2019, 14:33:27
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) 

Titel: Antw:Modul 96_SIP
Beitrag von: UweUwe am 08 Januar 2019, 19:40:18
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 08 Januar 2019, 20:35:18
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 :)
Titel: Antw:Modul 96_SIP
Beitrag von: UweUwe am 08 Januar 2019, 20:45:27
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".



Titel: Antw:Modul 96_SIP
Beitrag von: UweUwe am 08 Januar 2019, 21:14:44
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 10 Januar 2019, 20:23:36
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.
Titel: Antw:Modul 96_SIP
Beitrag von: UweUwe am 10 Januar 2019, 20:29:25
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
Titel: Antw:Modul 96_SIP
Beitrag von: DerTom am 16 Januar 2019, 19:54:27
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... :-[
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 16 Januar 2019, 20:16:19
TIPP : Eventmonitor öffenen , anrufen , Tasten drücken , den passenden Event im Monitor markieren und den Create/Modify Device Button drücken :)
Titel: Antw:Modul 96_SIP
Beitrag von: DerTom am 18 Januar 2019, 18:31:52
Oder so. Vielen Dank, der Tipp hat geholfen. Damit kann ich was anfangen.
Titel: Antw:Modul 96_SIP
Beitrag von: MarkusLoch am 21 Januar 2019, 21:15:25
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 22 Januar 2019, 07:37:44
gleiche Antwort wie immer : list vom Device posten und ein Log Abschnitt vom Vorgang mit verbose 5
Titel: Antw:Modul 96_SIP
Beitrag von: MarkusLoch am 22 Januar 2019, 16:27:46
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
Titel: Antw:Modul 96_SIP
Beitrag 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.
Titel: Antw:Modul 96_SIP
Beitrag von: MarkusLoch am 22 Januar 2019, 18:13:08
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!  :)
Titel: Antw:Modul 96_SIP
Beitrag von: no_Legend am 28 Januar 2019, 17:18:09
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 28 Januar 2019, 17:39:47
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 28 Januar 2019, 18:04:28
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
Titel: Antw:Modul 96_SIP
Beitrag von: Mikka am 28 Januar 2019, 20:39:48
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
Titel: Antw:Modul 96_SIP
Beitrag von: no_Legend am 28 Januar 2019, 21:06:34
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
Titel: Antw:Modul 96_SIP
Beitrag von: Mikka am 28 Januar 2019, 21:24:31
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
Titel: Antw:Modul 96_SIP
Beitrag von: no_Legend am 28 Januar 2019, 21:28:57
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
Titel: Antw:Modul 96_SIP
Beitrag von: Mikka am 28 Januar 2019, 21:30:50
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
Titel: Antw:Modul 96_SIP
Beitrag von: Mikka am 28 Januar 2019, 21:34:02
Screenshot habe ich soeben angehängt :-)

Viel Erfolg Morgen oder wann auch immer ;-)
Titel: Antw:Modul 96_SIP
Beitrag von: no_Legend am 28 Januar 2019, 21:37:29
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
Titel: Antw:Modul 96_SIP
Beitrag von: Mikka am 28 Januar 2019, 21:41:38
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 29 Januar 2019, 07:29:48
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. 
Titel: Antw:Modul 96_SIP
Beitrag von: no_Legend am 29 Januar 2019, 07:32:20
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
Titel: Antw:Modul 96_SIP
Beitrag von: no_Legend am 29 Januar 2019, 16:25:24
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.
Titel: Antw:Modul 96_SIP
Beitrag 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.
Titel: Antw:Modul 96_SIP
Beitrag von: Mikka am 29 Januar 2019, 18:57:56
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
Titel: Antw:Modul 96_SIP
Beitrag von: rayzyt am 30 März 2019, 19:39:37
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 31 März 2019, 09:02:51
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Elektrolurch am 04 Mai 2019, 18:43:25
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 16 Mai 2019, 19:51:41
Habe ich noch nicht gesehen. Welche Version von Net::SIP nutzt Du?

siehe "our $VERSION = '0.815';" in "/usr/share/perl5/Net/SIP.pm"
Titel: Antw:Modul 96_SIP
Beitrag 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.


/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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 05 Juni 2019, 17:42:25
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Isnogud0815 am 07 Juni 2019, 06:16:48
Moin,

der komplette Befehl lautet "set Doorbird Transmit_Audio /opt/fhem/audio/big_ben.mp3".

FhemModul 73_Doorbird.pm

Gruß
Siggi
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 07 Juni 2019, 14:39:47
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
Titel: Antw:Modul 96_SIP
Beitrag von: Isnogud0815 am 07 Juni 2019, 15:13:44
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 07 Juni 2019, 15:29:02
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
Titel: Antw:Modul 96_SIP
Beitrag von: Isnogud0815 am 18 Juni 2019, 12:28:30
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 18 Juni 2019, 12:50:50
works as desigend :) siehe Wiki
Wenn etwas anderes nach der Rufannahme passieren soll must das schon beim set call Aufruf mit übergeben
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 18 Juni 2019, 18:33:54
Ich spiele in dem Fall ein simples "Willkommen" ab.
Titel: Antw:Modul 96_SIP
Beitrag von: Dirk070 am 19 Juli 2019, 16:45:54
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

Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 19 Juli 2019, 19:18:10
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 ?
Titel: Antw:Modul 96_SIP
Beitrag von: Dirk070 am 20 Juli 2019, 15:36:02
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 20 Juli 2019, 18:16:50
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. 

Titel: Antw:Modul 96_SIP
Beitrag von: Dirk070 am 31 Juli 2019, 13:23:51
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.
Titel: Antw:Modul 96_SIP
Beitrag von: loescher am 01 August 2019, 22:21:53
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 02 August 2019, 08:14:19
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 ?
Titel: Antw:Modul 96_SIP
Beitrag von: loescher am 03 August 2019, 21:07:45
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 04 August 2019, 09:32:53
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 ;)
Titel: Antw:Modul 96_SIP
Beitrag von: Papaloewe am 10 August 2019, 18:21:34
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 10 August 2019, 20:02:51
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
Titel: Antw:Modul 96_SIP
Beitrag von: Papaloewe am 10 August 2019, 21:23:13
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....
Titel: Antw:Modul 96_SIP
Beitrag von: Papaloewe am 10 August 2019, 21:43:38
Die Kür wäre dann auch noch eine sogenannte strukturierte Notrufabfrage, aber jetzt bin ich schon etwas weit abgehoben.... ;-)
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 10 August 2019, 22:13:08
@Papaloewe: wenn Du viele komplizierte Dinge mit dem Telefon tun möchtest bietet sich asterisk an. Das gibts mittlerweile auch als docker image.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 11 August 2019, 08:21:01
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.   
Titel: Antw:Modul 96_SIP
Beitrag 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 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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 11 August 2019, 14:45:36
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 11 August 2019, 19:45:38
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 :)     
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 11 August 2019, 21:28:33
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 12 August 2019, 07:23:18
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.
Titel: Antw:Modul 96_SIP
Beitrag von: netbus am 17 Oktober 2019, 12:49:00
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 17 Oktober 2019, 13:18:59
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
Titel: Antw:Modul 96_SIP
Beitrag von: netbus am 17 Oktober 2019, 13:26:13
Danke, habe ihm mal geschrieben.
vG netbus
Titel: Antw:Modul 96_SIP
Beitrag von: netbus am 17 Oktober 2019, 14:31:52
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ß.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 17 Oktober 2019, 14:45:03
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 ?
Titel: Antw:Modul 96_SIP
Beitrag von: netbus am 17 Oktober 2019, 15:02:16
Ich möchte von Fhem (Sipclient) einen Call auf Doorbird (Sipclient) machen.
Beide befinden sich im selben LAN.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 21 Oktober 2019, 09:02:37
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.
Titel: Antw:Modul 96_SIP
Beitrag von: netbus am 21 Oktober 2019, 11:53:06
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 22 Oktober 2019, 07:33:46
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>

Titel: Antw:Modul 96_SIP
Beitrag von: netbus am 22 Oktober 2019, 11:56:02
Das funktioniert leider nicht (Herstellerseitig) obwohl in der API dokumentiert.
Daher der SIP workaround
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 22 Oktober 2019, 13:42:25
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 ? 
Titel: Antw:Modul 96_SIP
Beitrag von: loescher am 30 November 2019, 21:31:40
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 01 Dezember 2019, 07:28:58
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 :(
Titel: Antw:Modul 96_SIP
Beitrag von: itse-jens am 15 Dezember 2019, 14:31:15
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 15 Dezember 2019, 19:19:16
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 17 Dezember 2019, 22:16:37
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 ...
Titel: Antw:Modul 96_SIP
Beitrag von: pejonp am 01 Januar 2020, 21:41:57
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

Titel: Antw:Modul 96_SIP
Beitrag von: plin am 02 Januar 2020, 07:51:58
Moin,

ich habe da ein paar Fragen:



Titel: Antw:Modul 96_SIP
Beitrag von: pejonp am 02 Januar 2020, 09:21:22
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 02 Januar 2020, 10:06:06
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

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

VG plin
Titel: Antw:Modul 96_SIP
Beitrag von: pejonp am 02 Januar 2020, 15:08:33

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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 02 Januar 2020, 15:35:37
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:

Du musst Dir natürlich den Status "ringing" zwischenspeichern, damit Du den alten und den aktuellen Status vergleichen kannst.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 02 Januar 2020, 16:06:08
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
Titel: Antw:Modul 96_SIP
Beitrag 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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 17 Januar 2020, 22:39:48
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Newti64 am 17 Januar 2020, 22:56:08
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
Titel: Antw:Modul 96_SIP
Beitrag 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
Titel: Antw:Modul 96_SIP
Beitrag von: Newti64 am 18 Januar 2020, 09:43:25
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 18 Januar 2020, 15:08:10
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 :)
Titel: Antw:Modul 96_SIP
Beitrag von: Newti64 am 18 Januar 2020, 17:32:25
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
Titel: Antw:Modul 96_SIP
Beitrag von: Prof. Dr. Peter Henning am 19 Januar 2020, 12:53:57
pah hat demnächst hoffentlich wieder etwas Zeit ...

LG

pah
Titel: Antw:Modul 96_SIP
Beitrag von: bennebartsch am 23 Januar 2020, 13:57:17
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 23 Januar 2020, 14:25:05
timeout beim set Aufruf zu kurz gesetzt ? dann legt SIP auf bevor der Text durch ist :)

Titel: Antw:Modul 96_SIP
Beitrag von: bennebartsch am 23 Januar 2020, 16:15:21
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 23 Januar 2020, 16:31:13
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 :)
Titel: Antw:Modul 96_SIP
Beitrag 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.

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
Titel: Antw:Modul 96_SIP
Beitrag von: rob am 23 Januar 2020, 20:29:37
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
Titel: Antw:Modul 96_SIP
Beitrag von: frank am 23 Januar 2020, 20:33:05
das sind doch 11 minuten.
Titel: Antw:Modul 96_SIP
Beitrag von: rob am 23 Januar 2020, 20:49:58
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 24 Januar 2020, 09:15:19
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 )   

 
Titel: Antw:Modul 96_SIP
Beitrag von: bennebartsch am 24 Januar 2020, 13:08:56
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


Titel: Antw:Modul 96_SIP
Beitrag 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.

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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 24 Januar 2020, 17:30:07
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?
Titel: Antw:Modul 96_SIP
Beitrag von: bennebartsch am 24 Januar 2020, 18:32:58
Ä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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 25 Januar 2020, 10:18:08
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?
Titel: Antw:Modul 96_SIP
Beitrag von: bennebartsch am 25 Januar 2020, 12:31:14
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 25 Januar 2020, 13:56:30
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 )
Titel: Antw:Modul 96_SIP
Beitrag von: Tobbi am 25 Januar 2020, 22:55:46
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 26 Januar 2020, 09:00:21
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 ? 
Titel: Antw:Modul 96_SIP
Beitrag von: Tobbi am 26 Januar 2020, 12:17:21
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 26 Januar 2020, 13:03:51
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 ? ) 
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 26 Januar 2020, 13:07:01
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.
Titel: Antw:Modul 96_SIP
Beitrag 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 :(
Titel: Antw:Modul 96_SIP
Beitrag 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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 01 Februar 2020, 20:27:26
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 02 Februar 2020, 17:52:21
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 ?
Titel: Antw:Modul 96_SIP
Beitrag von: Tobbi am 02 Februar 2020, 19:09:39
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 02 Februar 2020, 19:35:07
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 ?
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 02 Februar 2020, 20:00:54
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Tobbi am 02 Februar 2020, 22:12:15
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.

Titel: Antw:Modul 96_SIP
Beitrag von: bown am 03 Februar 2020, 12:14:24
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 03 Februar 2020, 12:32:50
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
Titel: Antw:Modul 96_SIP
Beitrag von: bown am 03 Februar 2020, 21:56:40
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 03 März 2020, 09:07:58
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.
Titel: Antw:Modul 96_SIP
Beitrag von: loescher am 03 März 2020, 21:06:14
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.
Titel: Antw:Modul 96_SIP
Beitrag von: sledge am 09 März 2020, 14:30:47
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 21 März 2020, 20:34:56
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) 
Titel: Antw:Modul 96_SIP
Beitrag von: loescher am 22 März 2020, 21:25:15
Super! Vielen Dank!
LG,
Stephan.
Titel: Antw:Modul 96_SIP
Beitrag von: juemuc am 02 Mai 2020, 22:00:20
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


Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 03 Mai 2020, 07:02:07
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,
 
Titel: Antw:Modul 96_SIP
Beitrag von: juemuc am 03 Mai 2020, 12:09:21
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 03 Mai 2020, 13:06:33
dann must du den Wunsch an Steffen Ullrich richten , den Autor von Net::SIP.
Deine Fehlermeldung zeigt ja das Dispatcher.pm keinen Namen mag :)
Titel: Antw:Modul 96_SIP
Beitrag von: juemuc am 16 Mai 2020, 20:08:19
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 17 Mai 2020, 05:59:53
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.
Titel: Antw:Modul 96_SIP
Beitrag von: juemuc am 17 Mai 2020, 12:15:02
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
Titel: Antw:Modul 96_SIP
Beitrag von: Gisbert am 26 Juli 2020, 13:26:46
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 26 Juli 2020, 14:15:37
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 :)
Titel: Antw:Modul 96_SIP
Beitrag von: Gisbert am 26 Juli 2020, 17:31:16
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
Titel: Antw:Modul 96_SIP
Beitrag von: Gisbert am 26 Juli 2020, 17:48:19
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 26 Juli 2020, 18:11:50
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 26 Juli 2020, 18:37:29
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 02 August 2020, 17:39:32
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
Titel: Antw:Modul 96_SIP
Beitrag von: aHome77 am 11 August 2020, 16:08:24
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?
Titel: Antw:Modul 96_SIP
Beitrag 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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 11 August 2020, 20:59:46
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.box
caller_name Name
caller_nr nummer

Ein 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
Titel: Antw:Modul 96_SIP
Beitrag 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 ?

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. 
Titel: Antw:Modul 96_SIP
Beitrag 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.
Titel: Antw:Modul 96_SIP
Beitrag von: frank am 12 August 2020, 11:08:34
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.  ;)
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 12 August 2020, 13:58:40
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 12 August 2020, 14:06:29
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 12 August 2020, 14:09:38
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 ...
Titel: Antw:Modul 96_SIP
Beitrag von: aHome77 am 13 August 2020, 12:23:07
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 13 August 2020, 13:07:50
SIP Device ohne listen mode ? List vom Device zeigen
Titel: Antw:Modul 96_SIP
Beitrag von: aHome77 am 14 August 2020, 09:57:01
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

Titel: Antw:Modul 96_SIP
Beitrag von: frank am 14 August 2020, 10:00:14
attr FritzboxSipClient disabled 1
so kann es auch keine fehler geben, oder?
Titel: Antw:Modul 96_SIP
Beitrag von: aHome77 am 14 August 2020, 10:36:14
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...
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 20 August 2020, 09:41:37
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 20 August 2020, 09:50:55
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
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 20 August 2020, 10:31:24
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 20 August 2020, 10:51:08
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.
Titel: Antw:Modul 96_SIP
Beitrag von: frank am 20 August 2020, 11:28:35
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 20 August 2020, 11:37:53
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 20 August 2020, 12:26:44
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 20 August 2020, 12:58:30
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 ?
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 20 August 2020, 13:18:21
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 20 August 2020, 13:21:53
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 20 August 2020, 14:33:57
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 20 August 2020, 15:09:39
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 @
Titel: Antw:Modul 96_SIP
Beitrag 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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 20 August 2020, 15:57:23
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
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 20 August 2020, 16:17:00
Hallo Plin,
Fehler 401 ist verschwunden.

Weitere Ideen?

Danke und Gruß,
Kurt
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 20 August 2020, 16:51:27
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 20 August 2020, 17:12:07
Hallo Plin,
611 kann 621 nicht erreichen. D.h., dass nicht verbunden wird.

Danke und Gruß,
Kurt
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 20 August 2020, 17:16:24
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



Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 20 August 2020, 17:40:06
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 20 August 2020, 19:06:02
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 ?
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 20 August 2020, 19:29:19
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 21 August 2020, 07:32:44
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 :) 
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 21 August 2020, 08:43:54
siehe auch: https://wiki.fhem.de/wiki/SIP-Client#Docker (https://wiki.fhem.de/wiki/SIP-Client#Docker)
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 21 August 2020, 08:58:15
Hallo Wzut,
hier läuft Raspian (Debian Version 8.0) auf einem Raspi 3b. Welche Informationen brauchst Du noch?

Danke und Gruß,
Kurt
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 21 August 2020, 09:28:01
ok, dann versuchen wir es mal mit folgenden Aussagen:

und ein paar Tests/Fragen:

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.
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 21 August 2020, 12:16:44
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 21 August 2020, 14:15:26
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?

Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 21 August 2020, 14:19:58
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 ?
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 21 August 2020, 14:27:30
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)  ;)
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 21 August 2020, 14:40:16
Hallo Wzut,
Normales IP Phone.

Gruß Kurt
Titel: Antw:Modul 96_SIP
Beitrag 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.

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?
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 21 August 2020, 16:42:27
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
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 21 August 2020, 17:10:17
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 21 August 2020, 19:12:37
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. 
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 21 August 2020, 21:23:26
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 22 August 2020, 07:09:16
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. 
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 22 August 2020, 08:23:06
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
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 22 August 2020, 10:31:06
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 22 August 2020, 10:47:04
Was nutzt Du als Device für den Anruf?
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 22 August 2020, 10:52:00
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 22 August 2020, 11:11:44
Bei meinem FritzFON C5 höre ich weder die Ansage noch den Quittungston am Ende.

Wenn ich ein T2S Device anlege und die Attribute
belege kriege ich auch Ansagen.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 22 August 2020, 11:23:46
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 !
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 22 August 2020, 11:58:40
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
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 22 August 2020, 14:07:31
Hallo,
neue Erkenntnis: Nach einem reset funktioniert es zuverlässig immer genau 1-mal.
Hilft das bei der Fehlereingrenzung?

Danke und Gruß,
Kurt
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 22 August 2020, 14:17:44
@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 ?

Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 23 August 2020, 08:16:14
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 23 August 2020, 17:58:25
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
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 23 August 2020, 18:36:32
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 23 August 2020, 19:29:01
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
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 23 August 2020, 19:53:44
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 23 August 2020, 20:41:17
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 23 August 2020, 20:54:11
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 24 August 2020, 06:46:21
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 24 August 2020, 09:15:10
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 24 August 2020, 17:31:57
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 24 August 2020, 18:56:29
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 24 August 2020, 20:49:15
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
Titel: Antw:Modul 96_SIP
Beitrag von: Jamo am 24 August 2020, 21:04:25
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 24 August 2020, 21:07:02
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
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 24 August 2020, 21:21:49
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
Titel: Antw:Modul 96_SIP
Beitrag von: Jamo am 24 August 2020, 22:21:25
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:
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 24 August 2020, 22:44:32
Hallo Jamo,
versuchen wir es nochmal.

define irgendwas irgendwas


Passt das jetzt so?

Danke und Gruß,
Kurt
Titel: Antw:Modul 96_SIP
Beitrag von: Jamo am 24 August 2020, 23:27:04
Ja, sieht gut aus. Danke!
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 25 August 2020, 07:23:19
@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]



Titel: Antw:Modul 96_SIP
Beitrag von: plin am 25 August 2020, 18:43:08
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.

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

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

VG plin
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 25 August 2020, 19:21:32
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 25 August 2020, 20:07:41
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)  :).
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 26 August 2020, 09:00:32
Hallo,
danke für die Mühen, aber mir hilft das leider nicht.
Immer das gleiche Fehlerbild auch wenn ich Dateien einbinde.

Gruß Kurt
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 26 August 2020, 09:14:41
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 26 August 2020, 09:23:09
@Kurt: Welche Net::SIP-Version nutzt Du? Ich bin bei  our $VERSION = '0.808';
Titel: Antw:Modul 96_SIP
Beitrag 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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 26 August 2020, 10:16:59
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 26 August 2020, 12:31:26
@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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 26 August 2020, 13:17:36
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 26 August 2020, 14:03:08
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 26 August 2020, 14:53:29
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 26 August 2020, 15:02:30
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 26 August 2020, 15:04:49
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 ...
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 26 August 2020, 15:25:09
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 26 August 2020, 15:47:26
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 26 August 2020, 16:41:22
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 26 August 2020, 16:44:05
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 26 August 2020, 18:50:14
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
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 27 August 2020, 08:49:28
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 27 August 2020, 09:53:48
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 27 August 2020, 10:20:17
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
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 27 August 2020, 12:03:03
Hallo Wzut,
0.823 ist jetzt installiert. Keine Änderung.

Gruß Kurt

Titel: Antw:Modul 96_SIP
Beitrag von: plin am 27 August 2020, 12:15:28
Hallo Kurt,

welches Raspberry Pi Modell hast Du?

VG plin
Titel: Antw:Modul 96_SIP
Beitrag von: frank am 27 August 2020, 12:27:49
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 27 August 2020, 12:58:03
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 27 August 2020, 13:07:35
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)
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 27 August 2020, 14:02:44
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 27 August 2020, 14:46:51
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 27 August 2020, 14:57:09
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 27 August 2020, 16:12:01
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 27 August 2020, 20:28:48
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 C5
2020.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 iPhone
2020.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

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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 28 August 2020, 06:39:31
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 28 August 2020, 09:55:19
Ich denke Kurt hatte sich zu zwei Problemen geäußert

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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 28 August 2020, 14:30:12
das Problem ist in der nächsten Version gefixt
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 28 August 2020, 14:34:12
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
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 28 August 2020, 19:24:02
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 28 August 2020, 20:01:29
@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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 28 August 2020, 20:15:44
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 28 August 2020, 21:47:06
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
Titel: Antw:Modul 96_SIP
Beitrag von: Jamo am 28 August 2020, 22:36:55
Ja, mit deinen code tags sieht es jetzt super aus und man kann deine Beiträge gut lesen. Danke!
Titel: Antw:Modul 96_SIP
Beitrag 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 ?


Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 29 August 2020, 11:54:11
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 30 August 2020, 09:59:44
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 30 August 2020, 19:54:15
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.
Titel: Antw:Modul 96_SIP
Beitrag von: frank am 30 August 2020, 20:17:12
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 31 August 2020, 09:52:22
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 31 August 2020, 10:02:59
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 31 August 2020, 11:26:22
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 31 August 2020, 11:39:18
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 ?
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 31 August 2020, 11:49:04
Hallo Wzut,
keine Fehlermeldungen im Ereignisprotokoll. Anrufe mit call kommen durch.

Gruß Kurt
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 31 August 2020, 12:46:59
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?
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 31 August 2020, 13:06:54
@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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 31 August 2020, 14:19:57
kein Problem, ich habe z.B. ganz am Anfang einen erkannten Stern mit 9ms ohne das ich überhaupt ne Taste gedrückt habe ....
Titel: Antw:Modul 96_SIP
Beitrag 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?
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 31 August 2020, 16:27:32
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.

Titel: Antw:Modul 96_SIP
Beitrag von: plin am 31 August 2020, 16:57:41
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 31 August 2020, 18:01:20
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 01 September 2020, 11:10:43
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 01 September 2020, 11:49:24
@Kurt: Was ist denn mit den DTMF Events? Steht das Attribut verbose immer noch auf 5?
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 01 September 2020, 12:30:17
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 01 September 2020, 12:55:15
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 01 September 2020, 12:59:00
@Wzut: bedeutet neben der Net::SIP-Version sollten wir vielleicht auch den perl-Library path unter INTERNALS mit ausweisen?
perl -e "print qq(@INC)"
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 01 September 2020, 13:17:25
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 01 September 2020, 13:37:30
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
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 01 September 2020, 15:42:13
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 01 September 2020, 15:58:16
Dann könnte man jetzt noch ein
find /usr/ -name "SIP.pm"
hinterherschieben, um zu sehen, ob es das File mehrfach gibt.
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 01 September 2020, 16:10:33
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 01 September 2020, 16:23:27
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Kurt77 am 01 September 2020, 16:40:28
Hallo Wzut,
ja, sorry, die fehlelnden Zeichen "96_" hatte ich übersehen.

Deine Testversion zeigt jedenfalls jetzt:


   NetSIP     0.823


Gruß Kurt
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 01 September 2020, 17:15:24
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)
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 01 September 2020, 18:31:52
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 01 September 2020, 19:20:20
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 02 September 2020, 08:07:20
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 02 September 2020, 09:13:35
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 02 September 2020, 09:29:18
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 03 September 2020, 07:28:05
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. 
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 03 September 2020, 08:41:41
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 03 September 2020, 15:36:37
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:

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
Titel: Antw:Modul 96_SIP
Beitrag 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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 05 September 2020, 15:20:22
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).
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 05 September 2020, 17:22:45
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 :(
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 09 September 2020, 07:18:17
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 09 September 2020, 09:51:39
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 09 September 2020, 19:27:40
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 09 September 2020, 20:13:38
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 13 September 2020, 18:53:26
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 14 September 2020, 20:42:03
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 15 September 2020, 06:45:24
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')}
Titel: Antw:Modul 96_SIP
Beitrag von: en-trust am 14 Oktober 2020, 14:28:32
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 14 Oktober 2020, 16:25:22
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.   
Titel: Antw:Modul 96_SIP
Beitrag von: en-trust am 14 Oktober 2020, 20:41:37
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 15 Oktober 2020, 07:47:19
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 ?
Titel: Antw:Modul 96_SIP
Beitrag von: en-trust am 15 Oktober 2020, 13:39:09
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...
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 15 Oktober 2020, 17:06:00
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
Titel: Antw:Modul 96_SIP
Beitrag von: en-trust am 16 Oktober 2020, 07:41:55
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).
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 16 Oktober 2020, 08:16:23
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 ?



Titel: Antw:Modul 96_SIP
Beitrag von: plin am 16 Oktober 2020, 09:32:54
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?
Titel: Antw:Modul 96_SIP
Beitrag von: frank am 16 Oktober 2020, 09:59:40
perl 5.20.3 ist eine perl version ohne memory leaks.
Titel: Antw:Modul 96_SIP
Beitrag von: en-trust am 16 Oktober 2020, 10:16:41
/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.
Titel: Antw:Modul 96_SIP
Beitrag von: MadMax-FHEM am 16 Oktober 2020, 10:19:46
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
Titel: Antw:Modul 96_SIP
Beitrag von: en-trust am 16 Oktober 2020, 11:30:16
über apt update && apt full-upgrade ist scheinbar perl 5.28.x nicht verfügbar
Titel: Antw:Modul 96_SIP
Beitrag von: MadMax-FHEM am 16 Oktober 2020, 11:35:09
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
Titel: Antw:Modul 96_SIP
Beitrag von: en-trust am 16 Oktober 2020, 11:41:27
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...
Titel: Antw:Modul 96_SIP
Beitrag von: MadMax-FHEM am 16 Oktober 2020, 11:44:06
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
Titel: Antw:Modul 96_SIP
Beitrag von: Beta-User am 16 Oktober 2020, 11:45:36
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 ...
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 16 Oktober 2020, 13:36:01
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 !
Titel: Antw:Modul 96_SIP
Beitrag von: Elektrolurch am 25 Oktober 2020, 10:26:26
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 25 Oktober 2020, 11:18:04
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.
Titel: Antw:Modul 96_SIP
Beitrag von: en-trust am 27 Oktober 2020, 10:19:34
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 27 Oktober 2020, 12:09:42
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wolle02 am 27 Oktober 2020, 13:52:13
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 27 Oktober 2020, 17:15:05
versuch mal set <name> reset, dass killt einen aktiven Child Prozess.
Titel: Antw:Modul 96_SIP
Beitrag von: Wolle02 am 27 Oktober 2020, 18:30:25
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".    :-[
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 27 Oktober 2020, 20:14:54
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wolle02 am 28 Oktober 2020, 05:51:02
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 28 Oktober 2020, 07:01:38
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wolle02 am 28 Oktober 2020, 07:51:35
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 28 Oktober 2020, 08:18:29
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 .....
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 28 Oktober 2020, 18:10:49
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.
Titel: Antw:Modul 96_SIP
Beitrag von: thunder1902 am 16 November 2020, 18:36:59
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??
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 16 November 2020, 18:48:07
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wolle02 am 21 November 2020, 09:19:00
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 21 November 2020, 10:32:17
@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
Titel: Antw:Modul 96_SIP
Beitrag 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 ?
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 ?
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 22 November 2020, 09:53:13
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?
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 24 November 2020, 21:12:01
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  :).
Titel: Antw:Modul 96_SIP
Beitrag 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

      
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 08 Februar 2021, 18:29:40
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.
Titel: Antw:Modul 96_SIP
Beitrag von: pwlr am 09 Februar 2021, 16:27:36
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
Titel: Antw:Modul 96_SIP
Beitrag von: Elektrolurch am 11 März 2021, 12:49:02
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 11 März 2021, 13:22:59
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
Titel: Antw:Modul 96_SIP
Beitrag von: Elektrolurch am 15 März 2021, 16:39:23
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


Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 15 März 2021, 17:13:32
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. 
Titel: Antw:Modul 96_SIP
Beitrag von: pejonp am 15 März 2021, 17:54:52

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
Titel: Antw:Modul 96_SIP
Beitrag von: Elektrolurch am 15 März 2021, 19:16:55
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

Titel: Antw:Modul 96_SIP
Beitrag von: juemuc am 15 März 2021, 19:44:47
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 15 März 2021, 20:05:55
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.
Titel: Antw:Modul 96_SIP
Beitrag von: juemuc am 15 März 2021, 20:38:13
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 16 März 2021, 07:41:20
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 16 März 2021, 07:56:20
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Elektrolurch am 16 März 2021, 11:09:51
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

Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 16 März 2021, 14:02:01
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.
Titel: Antw:Modul 96_SIP
Beitrag von: juemuc am 16 März 2021, 20:11:39
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
Titel: Antw:Modul 96_SIP
Beitrag von: juemuc am 16 März 2021, 22:40:46
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
Titel: Antw:Modul 96_SIP
Beitrag von: Elektrolurch am 17 März 2021, 12:13:06
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 17 März 2021, 16:38:48
@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.
 
Titel: Antw:Modul 96_SIP
Beitrag von: Elektrolurch am 19 März 2021, 11:05:03
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 19 März 2021, 12:53:56
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Tiffytaffy am 06 April 2021, 11:36:49
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ß
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 06 April 2021, 21:19:37
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Tiffytaffy am 06 April 2021, 23:52:28
@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.

Titel: Antw:Modul 96_SIP
Beitrag von: plin am 07 April 2021, 21:34:55
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Tiffytaffy am 07 April 2021, 22:20:29
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
Titel: Antw:Modul 96_SIP
Beitrag von: kunksmuhme am 11 April 2021, 23:11:17
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]
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 12 April 2021, 06:57:41
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 ....
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 12 April 2021, 08:08:20
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?
Titel: Antw:Modul 96_SIP
Beitrag von: trabantp60 am 20 April 2021, 20:28:49
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 21 April 2021, 07:37:00
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.
Titel: Antw:Modul 96_SIP
Beitrag von: trabantp60 am 21 April 2021, 08:06:30
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 21 April 2021, 08:17:50
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

Titel: Antw:Modul 96_SIP
Beitrag 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"
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 05 Mai 2021, 08:08:45
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 ?   
Titel: Antw:Modul 96_SIP
Beitrag von: hansdepp am 05 Mai 2021, 17:54:41
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 06 Mai 2021, 08:24:55
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 ?
Titel: Antw:Modul 96_SIP
Beitrag von: hansdepp am 06 Mai 2021, 20:53:21
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 07 Mai 2021, 07:21:59
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.

Titel: Antw:Modul 96_SIP
Beitrag von: plin am 07 Mai 2021, 14:07:27
09811234567 heißt Du rufst auf einem Endgerät im Festnetz an? Was hängt denn da am anderen Ende? Analog, ISDN, SIP, Telefonanlage???
Titel: Antw:Modul 96_SIP
Beitrag 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.
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 07 Mai 2021, 20:38:32
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 07 Mai 2021, 20:39:32
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?
Titel: Antw:Modul 96_SIP
Beitrag 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.

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?
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 08 Mai 2021, 09:10:19
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?
Titel: Antw:Modul 96_SIP
Beitrag von: hansdepp am 08 Mai 2021, 09:38:24
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?
Titel: Antw:Modul 96_SIP
Beitrag von: laufhem am 23 August 2021, 11:45:02
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Frood42 am 16 September 2021, 10:41:48
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 16 September 2021, 10:46:39
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Frood42 am 16 September 2021, 12:12:25
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
Titel: Antw:Modul 96_SIP
Beitrag von: FHEMAN am 21 September 2021, 18:27:29
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
Titel: Antw:Modul 96_SIP
Beitrag von: FHEMAN am 21 September 2021, 18:34:25
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
Titel: Antw:Modul 96_SIP: [GELÖST]
Beitrag von: frankreed am 06 Oktober 2021, 15:42:36
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.


Titel: Antw:Modul 96_SIP
Beitrag 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?
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 09 Oktober 2021, 20:47:16
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 09 Oktober 2021, 20:59:20
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
Titel: Antw:Modul 96_SIP
Beitrag von: Fillip am 16 Oktober 2021, 23:13:16
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?
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 17 Oktober 2021, 10:27:48
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Muschelpuster am 18 Oktober 2021, 07:59:46
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 18 Oktober 2021, 18:37:35
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???
Titel: Antw:Modul 96_SIP
Beitrag von: Muschelpuster am 18 Oktober 2021, 20:32:20
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 20 Oktober 2021, 21:03:45
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
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 ...
Titel: Antw:Modul 96_SIP
Beitrag von: tremichl am 12 November 2021, 18:32:47
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


   
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 13 November 2021, 10:23:00
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
Titel: Antw:Modul 96_SIP
Beitrag von: tremichl am 13 November 2021, 12:08:38
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 13 November 2021, 14:24:42
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.
Titel: Antw:Modul 96_SIP
Beitrag 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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 14 November 2021, 10:47:00
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
Ist das der gedachte Ablauf???

VG Peter
Titel: Antw:Modul 96_SIP
Beitrag von: tremichl am 14 November 2021, 12:24:17
ja, ich habe der Einfachheit halber nur beschrieben was das SIP Modul machen soll. Hier der gesamte Vorgang:


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


Titel: Antw:Modul 96_SIP
Beitrag von: hansdepp am 23 Dezember 2021, 09:07:52
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!
Titel: Antw:Modul 96_SIP
Beitrag von: fuchsnase am 27 April 2022, 00:56:32
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 27 April 2022, 09:23:54
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* ? 
Titel: Antw:Modul 96_SIP
Beitrag von: Gisbert am 18 Juli 2022, 20:28:56
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
Titel: Antw:Modul 96_SIP
Beitrag von: Gisbert am 18 Juli 2022, 21:51:40
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 20 Juli 2022, 16:00:50
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

Titel: Antw:Modul 96_SIP
Beitrag von: Flachzange am 11 August 2022, 21:06:56
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 12 August 2022, 11:42:19
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 12 August 2022, 13:29:41
Konkret: In der Util.pm kannst Du
our $RTP_MIN_PORT = 2000;
our $RTP_MAX_PORT = 12000;

nach oben legen
Titel: Antw:Modul 96_SIP
Beitrag von: Flachzange am 12 August 2022, 17:35:48
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.

Titel: Antw:Modul 96_SIP
Beitrag von: Flachzange am 14 August 2022, 20:07:15
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!
Titel: Antw:Modul 96_SIP
Beitrag von: rob am 15 August 2022, 12:51:36
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
Titel: Antw:Modul 96_SIP
Beitrag von: Flachzange am 16 August 2022, 06:19:23
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?
Titel: Antw:Modul 96_SIP
Beitrag von: rob am 17 August 2022, 10:10:49
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  ;)
Titel: Antw:Modul 96_SIP
Beitrag von: Flachzange am 17 August 2022, 22:51:09
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 17 August 2022, 23:06:42
wzut ...
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 20 August 2022, 11:57:24
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.
Titel: Antw:Modul 96_SIP
Beitrag 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.

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.
Titel: Antw:Modul 96_SIP
Beitrag von: Flachzange am 20 August 2022, 13:48:36
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.
Titel: Antw:Modul 96_SIP
Beitrag von: amehl am 31 August 2022, 09:50:48
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 01 September 2022, 11:54:25
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. 
Titel: Antw:Modul 96_SIP
Beitrag von: amehl am 01 September 2022, 12:37:42
Danke für die Info. Ich hab noch einen alten Raspi rumliegen, vielleicht löse ich es auch so.

Grüße
Andi
Titel: Antw:Modul 96_SIP
Beitrag von: amehl am 16 Oktober 2022, 09:39:52
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 16 Oktober 2022, 10:58:27
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.
Titel: Antw:Modul 96_SIP
Beitrag von: amehl am 16 Oktober 2022, 19:57:03
Vielen Dank das war es - frage mich nur warum der Ordner nur auf owner pi war???
Titel: Antw:Modul 96_SIP
Beitrag von: FHEMAN am 30 Oktober 2022, 21:16:30
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Gisbert am 22 November 2022, 21:56:49
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 22 November 2022, 23:37:32
Hallo Gisbert,

Kannst Du bitte mal verbose auf 5 setzen, den Vorgang wiederholen und den Log-Auszug posten.

VG Peter
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 23 November 2022, 09:19:15
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 ?
Titel: Antw:Modul 96_SIP
Beitrag von: Gisbert am 23 November 2022, 10:28:27
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
Titel: Antw:Modul 96_SIP
Beitrag von: schenkl am 06 Februar 2023, 21:03:14
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




Titel: Antw:Modul 96_SIP
Beitrag von: rob am 06 Februar 2023, 22:18:15
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
Titel: Antw:Modul 96_SIP
Beitrag von: schenkl am 02 März 2023, 10:32:28
Danke Rob, genau das hat funktioniert.
Titel: Antw:Modul 96_SIP
Beitrag von: Homalix99 am 04 März 2023, 18:01:59
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
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 04 März 2023, 18:16:31
Bitte Wiki lesen, da steht schon lange die Lösung für Docker und RTP Ports !



Titel: Antw:Modul 96_SIP
Beitrag von: Homalix99 am 06 März 2023, 20:23:19
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 07 März 2023, 09:56:35
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Homalix99 am 07 März 2023, 11:23:53
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



Titel: Antw:Modul 96_SIP
Beitrag von: plin am 07 März 2023, 15:59:53
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)?
Titel: Antw:Modul 96_SIP
Beitrag von: Homalix99 am 07 März 2023, 22:14:40
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 08 März 2023, 13:21:38
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Homalix99 am 08 März 2023, 18:43:45
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 08 März 2023, 19:50:33
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
Titel: Antw:Modul 96_SIP
Beitrag von: Homalix99 am 08 März 2023, 20:09:17
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 08 März 2023, 20:56:33
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".
Titel: Antw:Modul 96_SIP
Beitrag von: Homalix99 am 08 März 2023, 22:15:01
Okay,

das klingt ja schon mal nicht nach einem fhem Problem.
Vielen Dank für die aufwendige Analyse. Aber was kann es sonst sein?
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 09 März 2023, 12:53:48
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Homalix99 am 09 März 2023, 16:35:20
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 09 März 2023, 18:17:02
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?
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 09 März 2023, 20:04:08
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.
Titel: Antw:Modul 96_SIP
Beitrag von: Homalix99 am 09 März 2023, 20:17:32
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?
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 09 März 2023, 20:20:58
Hast Du Docker mit NATing eingerichtet???

Schick doch mal ip addr und ip route von innerhalb des Containers und vom Host.
Titel: Antw:Modul 96_SIP
Beitrag von: Homalix99 am 09 März 2023, 20:36:14
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Homalix99 am 09 März 2023, 22:30:48
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#


Titel: Antw:Modul 96_SIP
Beitrag von: plin am 10 März 2023, 12:56:45
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 ...
Titel: Antw:Modul 96_SIP
Beitrag von: Homalix99 am 10 März 2023, 13:32:05
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?
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 10 März 2023, 16:05:34
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 10 März 2023, 18:00:50
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Homalix99 am 10 März 2023, 20:47:32
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
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 11 März 2023, 10:05:40
Mal schauen wann sich wzut einklinkt. Vielleicht hat der noch eine Idee.
Titel: Antw:Modul 96_SIP
Beitrag von: Homalix99 am 11 März 2023, 12:28:50
Vielen, vielen Dank erstmal für Deine Unterstützung.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 11 März 2023, 17:55:09
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?
Titel: Antw:Modul 96_SIP
Beitrag von: Wzut am 11 März 2023, 18:39:12
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.
Titel: Antw:Modul 96_SIP
Beitrag von: plin am 12 März 2023, 15:50:32
Alex, frag doch mal matrois was er damals gemacht hat https://forum.fhem.de/index.php/topic,102206.msg958302.html#msg958302
Titel: Antw:Modul 96_SIP
Beitrag von: rob am 13 März 2023, 13:01:07
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
Titel: Antw:Modul 96_SIP
Beitrag von: Homalix99 am 16 März 2023, 21:07:30
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
Titel: Aw: Modul 96_SIP
Beitrag von: RalfRog am 03 April 2023, 20:00:44
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 SIP

Welchen FQDN meint die Meldung? Meine FritzBox als SIP-Server ist mit der IP definiert.

Titel: Aw: Modul 96_SIP
Beitrag von: JoWiemann am 03 April 2023, 20:42:44
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
Titel: Aw: Modul 96_SIP
Beitrag von: plin am 03 April 2023, 20:47:58
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.
Titel: Aw: Modul 96_SIP
Beitrag von: JoWiemann am 03 April 2023, 21:18:29
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
Titel: Aw: Modul 96_SIP
Beitrag von: plin am 03 April 2023, 21:23:23
Mmmh, habe das hier gefunden: https://bugs.launchpad.net/ubuntu/+source/libhttp-daemon-perl/+bug/1904907

Welche OS-Version hast Du im Einsatz?
Titel: Aw: Modul 96_SIP
Beitrag von: JoWiemann am 03 April 2023, 21:29:26
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
Titel: Aw: Modul 96_SIP
Beitrag von: RalfRog am 03 April 2023, 21:31:43
Häng was hinterher...

Bei mir ist es ebenfalls Buster und die Ausgaben (hostname, hostname -f, ip a) analog zu Jo
Titel: Aw: Modul 96_SIP
Beitrag von: plin am 03 April 2023, 21:51:29
Ich kann bei mir unter openSUSE Leap 15.4 im fhem-log überhaupt keine dieser Meldungen finden...
Titel: Aw: Modul 96_SIP
Beitrag von: RalfRog am 03 April 2023, 23:19:30
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
Titel: Aw: Modul 96_SIP
Beitrag von: plin am 04 April 2023, 09:19:32
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
Titel: Aw: Modul 96_SIP
Beitrag von: RalfRog am 04 April 2023, 12:12:55
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
Titel: Aw: Modul 96_SIP
Beitrag von: Navigator am 15 April 2023, 15:20:35
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

Titel: Aw: Modul 96_SIP
Beitrag von: RalfRog am 15 April 2023, 17:25:22
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.
Titel: Aw: Modul 96_SIP
Beitrag von: plin am 15 April 2023, 21:04:19
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?
Titel: Aw: Modul 96_SIP
Beitrag von: Navigator am 16 April 2023, 12:48:50
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
Titel: Aw: Modul 96_SIP
Beitrag von: plin am 16 April 2023, 18:54:35
Bei mir ist die
Installed: 0.822installiert.

Upate: bin jetzt bei: Installed: 0.835
Titel: Aw: Modul 96_SIP
Beitrag von: Navigator am 17 April 2023, 21:27:29
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.
Titel: Aw: Modul 96_SIP
Beitrag von: laserrichi am 17 Mai 2023, 18:27:21
Zitat von: FHEMAN am 30 Oktober 2022, 21:16:30
Zitat 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 ?
Titel: Aw: Modul 96_SIP
Beitrag von: Onkel.Tom am 07 März 2024, 16:59:49
Zitat von: plin am 13 November 2021, 10:23:00
Zitat 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
Titel: Aw: Modul 96_SIP
Beitrag von: plin am 17 März 2024, 08:28:55
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