Modul 96_SIP

[plin]

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.

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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.

[pwlr]

Moin,

Ich 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,

Funktioniert 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

[Elektrolurch]

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

[Wzut]

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

[Elektrolurch]

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:

Code Auswählen Erweitern


sip_ip 192.168.1.16

auf das korekte Interface 1 zeigen sollte.
Im log bekomme ich jedoch:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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

[Wzut]

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. 

[pejonp]

Code Auswählen Erweitern


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

[Elektrolurch]

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

[juemuc]

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

[Wzut]

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.

[juemuc]

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 

Viele Grüße
Jürgen

[plin]

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.

[Wzut]

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.

[Elektrolurch]

An den Internals kann ich nicht erkennen, was da schief läuft:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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



[Wzut]

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.