Hauptmenü

Modul 96_SIP

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

Vorheriges Thema - Nächstes Thema

knodono

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.

RaspiCOC

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...  :'(

frank

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
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Wzut

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

frank

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.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Wzut

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

Wzut

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

frank

danke, aber ich kann leider erst kommende woche testen.

gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

moeweflieg

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

Wzut

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

frank

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.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Wzut

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

moeweflieg

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

Mikka

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

Wzut

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