Hauptmenü

Modul 96_SIP

Begonnen von Wzut, 19 Februar 2017, 19:10:09

Vorheriges Thema - Nächstes Thema

tpm88

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
Test FHEM Server on RPi, CUL_HM
Prod FHEM Server on Odroid HC1, HM-USB, JeeLink
Devices: diverse HM, IT1500, 1wire, LaCrosse, MQTT

Wzut

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.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

tpm88

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
Test FHEM Server on RPi, CUL_HM
Prod FHEM Server on Odroid HC1, HM-USB, JeeLink
Devices: diverse HM, IT1500, 1wire, LaCrosse, MQTT

Wzut

Ich schau mir das morgen oder am WE nochmal in Ruhe an und schneide ggf. zwischen : und @
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

plin

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 ...
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

plin

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."
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

magichand

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

plin

@magichand: Wo hast Du Dein Docker-Image her? Dann kann ich versuchen das Problem nachzustellen.
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

plin

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.
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

Wzut

#654
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.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

tpm88

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
Test FHEM Server on RPi, CUL_HM
Prod FHEM Server on Odroid HC1, HM-USB, JeeLink
Devices: diverse HM, IT1500, 1wire, LaCrosse, MQTT

magichand

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

tpm88

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
Test FHEM Server on RPi, CUL_HM
Prod FHEM Server on Odroid HC1, HM-USB, JeeLink
Devices: diverse HM, IT1500, 1wire, LaCrosse, MQTT

Wzut

@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
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

tpm88

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
Test FHEM Server on RPi, CUL_HM
Prod FHEM Server on Odroid HC1, HM-USB, JeeLink
Devices: diverse HM, IT1500, 1wire, LaCrosse, MQTT