Hauptmenü

Modul 96_SIP

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

Vorheriges Thema - Nächstes Thema

Wzut

geh mal ein paar Seiten hier zurück bis Antwort #311 und folgende, da hatten wir das Thema Docker schon einmal.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

The-Holgi

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
HP T610 Thin Client; Docker Fhem 5.9; 2X CUL V3 868mhz; Max Heizungssteuerung; FS20kse; FS20UWS; FS20S8-3; 2 FS20DI; HM-CFG-LAN,HM-LC-SW1-PL,HM-SEC-SD, HM-SE1PBU-FM;
Harmony Hub;Hue-Bridge mit Iris, E27 Bulb & FLS-PP

markus1407

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.

Wzut

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

SirUli

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 ;)


UweUwe

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



UweUwe

Die Änderung des IP Adresse hat nicht geändert, hab auch vor einem neuen Anruf set .. reset gemacht.

UweUwe

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









Wzut

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) 

Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

UweUwe

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.

Wzut

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

UweUwe

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




UweUwe

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.

plin

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

UweUwe

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