Modul 96_SIP

[Wzut]

FHEM mal neu gestartet  ?
Der DTMF Listen Prozess hat sonst keine Ahnung davon das jetzt MySipClient.sip vorhanden ist.
D.h. Write_history loggt eigentlich jede Art von Anruf, egal ob in oder out und erfolgreich oder nicht.

[pechnase]

Hallo,
ich verwende bis jetzt asterisk als SIP-Client mit einem in der Fritz!Box angelegten 'SIP-Telefon'.
Das SIP-Telefon verwende ich als Klingel Weiterleitung, d.h. wenn jemand an der Haustür klingelt, klingelt auch ein DECT-Telefon, das intern über das SIP-Telefon angerufen wird. Auf dem Display des DECT-Telefons erscheint dann 'es klingelt', weil ich das als CallerID über asterisk weitergebe.
Ich möchte jetzt auf das SIP-Modul umstellen, was auch soweit funktioniert, nur das mit der CallerID bekomme ich nicht hin. Gibt es in dem SIP-Modul z.B. ein Attribut sip-callerid oder etwas in diese Richtung?
Ich habe das Forum durchsucht, aber keine Lösung gefunden.
Danke für einen Hinweis.

Wolfgang

[plin]

Hi,

die Caller Id wird von der FritzBox vorgegeben. Du musst in der FB unter Telefonie->Telefoniegräte dem SIP-Client den Namen "es klingelt" geben.

VG plin

[Elektrolurch]

Hallo wzut und sip - Freunde,

ich benutze das Modul schon seit  Jahren für
a) Textnachrichten an Telefonnummern zu senden und
b) Wenn der Rechner von bestimmten externen Nummern angerufen wird, wierd das Gespräch entgegengenommen und eine Textnachricht abgespielt.
Das funktionierte jetz seit Jahren einwandfrei.
Nun habe ich meine alte 7390 durch eine 7590 ersetzt.
b) eingehende Anrufe annehmen und eine generierte Nachricht abspielen funktioniert weiterhin
a) Der Anruf wird gestartet und das angerufene Telefon klingelt. Hebt man ab, wird aber keine Nachricht, bzw. das vom sip - Cleint generierte Audiofile .alaw abgespielt. tts erzeugt das .mp3 und sip das .alaw. Also an Dateirechten kann es nicht liegen.
Merkwürdigerweise steht ein "cancel" im log drin, wenn  das angerufene Telefon den call annimt (verbose 4).

Code Auswählen Erweitern

2025.08.16 13:13:55 3: sip_not: sip rd listen_alive val 103751
2025.08.16 13:13:55 3: sip_not: sip rd call_state val calling
2025.08.16 13:14:08 4: sip[103751], cb_final - status : FAIL - final : 486
2025.08.16 13:14:08 4: sip[103751], Calltime : 0
2025.08.16 13:14:08 4: sip, CALLDone -> sip|1|canceled|0
2025.08.16 13:14:08 3: sip_not: sip rd call val done
2025.08.16 13:14:08 3: sip_not: sip rd call_state val canceled
2025.08.16 13:14:08 3: sip_not: sip rd listen_wfp val
Hier die Attribute:

Code Auswählen Erweitern

T2S_Device tts
audio_converter sox
disabled 0
event-on-change-reading .*
history_file ./log/sip.sip
history_size 0
sip_audiofile_wfp /hdd/sda4/Sonos/speak/report.alaw
sip_call_audio_delay 2.25
sip_dtmf_loop once
sip_dtmf_send audioattr sip sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc no
sip_force_interval 300
registrar und user habe ich hier mal weggelassen, da ja die generierte Datei report.alaw bei eingehenden Anrufen gesendet werden kann, also  der sip - Client an der fb korrekt angemeldet ist.
Die von tts erzeugte mp3 Datei lässt sich abspielen und enthält den Text der Nachricht.
Aufruf

set sip call **612 30 !Die Waschmaschine ist fertig


Hier ein TEil der relevanten readings / internals:

Code Auswählen Erweitern

   STATE      listen_wfp
   TYPE       SIP
   VERSION    V1.92 / 21.03.2020
   eventCount 51
   READINGS:
     2025-08-16 12:48:15   call            done
     2025-08-16 12:48:15   call_attempt    0
     2025-08-16 12:48:15   call_state      canceled
     2025-08-16 12:48:15   call_success    0
     2025-08-16 12:48:15   call_time       0
     2025-08-16 11:34:04   caller          none
     2025-08-16 11:34:04   caller_name     ---
     2025-08-16 11:34:04   caller_nr       ---
     2025-08-16 11:34:04   caller_state    waiting
     2025-08-16 11:34:04   caller_time     0
     2025-08-16 13:05:26   expire          300

Auch hier der Status des ausgehenden Anrufes mit "canceled" und Dauer 0.

Wie oben gesagt: aktuelle FB mit 7590  und das Problem ist erst nach dem Wechsel der FB.
Jemand eine Idee? Wenn der ausgehende Anruf mit dem Status "canceld"  abgebrochen wird, obwohl ich  das GEspräch annehme, würde das erklären, dass die Nachricht nicht abgespielt werden kann.


Jemand eine Idee zur Lösung?

Elektrolurch

[Wzut]

Vermutlich hast du nicht nur die Hardware angehoben sondern vllt. auch damit das OS der Fritte ?
Ich bin seit ewigen Zeiten auf einer 7490 unterwegs und das letzte OS Update war auf 7.12

Wäre jetzt intressant zu wissen was andere User so an aktueller Hardware bzw. FritzOS zusammen mit dem SIP Modul im Einsatz habe.

[Wzut]

Nachtrag : Ich müsste mal die Fehlermeldung überarbeiten : 486 ist nicht canceled - das ist 487
486 ist "Busy Here" auf gut deutsch : besetzt

[Elektrolurch]

7590 mit OS 8.02. Wenn auf dem sip client ein Anruf eingeht, geht die automatische Beantwortung mit einer Sprachnachricht. Nur bei einem ausgehenden Anruf wird der Anruf sofort beendet, wenn man abnimmt, egal ob internes Mobilteil oder externe Nummer. Habe das mal mit dem 2großen Freund" durchdiskutiert und einige Varianten ausprobiert. Er ist dann zum Ergebnis gekommen, dass es mit der Version 8.02 ein Problem mit dem sip - Handshake bestehen könnte.... 

[juemuc]

Hallo zusammen,

nachdem ich hier vom Problem von Elektrolurch gelesen habe, habe ich direkt mal meine SIP-Nachricht getestet und festgestellt, dass ich zwar angerufen werden, aber keine Sprachnachricht ankommt. Ein Log mit verbose 4 zeigt mir keine Auffälligkeiten:

Code Auswählen Erweitern

2025.08.16 19:25:05.831 4: FB_SIP, wait_for_t2s file : cache/3af183df28c80149fd2621b2c7133adb.mp3
2025.08.16 19:25:05.831 4: FB_SIP, new T2S file cache/3af183df28c80149fd2621b2c7133adb.mp3
2025.08.16 19:25:05.832 4: FB_SIP, audio file cache/3af183df28c80149fd2621b2c7133adb.alaw found
2025.08.16 19:25:05.832 4: FB_SIP, FB_SIP|TELEFONNUMMER|40|cache/3af183df28c80149fd2621b2c7133adb.alaw|0
2025.08.16 19:25:05.837 4: FB_SIP, call -> FB_SIP|TELEFONNUMMER|40|cache/3af183df28c80149fd2621b2c7133adb.alaw|0|0
2025.08.16 19:25:05.843 4: FB_SIP[2375670], my parent is 1058279
2025.08.16 19:25:05.844 4: FB_SIP[2375670], using Leg.pm to find a free port
2025.08.16 19:25:05.863 4: FB_SIP[2375670], register new expire : 2025-08-16 19:30:05
2025.08.16 19:25:05.873 4: FB_SIP[2375670], CallStart with 1 files - first file : cache/3af183df28c80149fd2621b2c7133adb.alaw - PCMA/8000 , repeat 0
2025.08.16 19:25:05.876 4: FB_SIP[2375670], calling : TELEFONNUMMER
2025.08.16 19:25:10.494 4: FB_SIP[2375670], cb_final - status : OK
2025.08.16 19:25:10.494 4: FB_SIP[2375670], call established
2025.08.16 19:25:13.863 4: FB_SIP[2375670], Calltime : 3
2025.08.16 19:25:13.870 4: FB_SIP, CALLDone -> FB_SIP|1|ok|3
2025.08.16 19:28:28.118 4: FB_SIP, wait_for_t2s file : cache/17c5e5e7989d8c8c1ca8b9fb6436c960.mp3
2025.08.16 19:28:28.118 4: FB_SIP, new T2S file cache/17c5e5e7989d8c8c1ca8b9fb6436c960.mp3
2025.08.16 19:28:28.138 4: FB_SIP, audio file cache/17c5e5e7989d8c8c1ca8b9fb6436c960.alaw found
2025.08.16 19:28:28.138 4: FB_SIP, FB_SIP|TELEFONNUMMER|20|cache/17c5e5e7989d8c8c1ca8b9fb6436c960.alaw|0
2025.08.16 19:28:28.144 4: FB_SIP, call -> FB_SIP|TELEFONNUMMER|20|cache/17c5e5e7989d8c8c1ca8b9fb6436c960.alaw|0|0
2025.08.16 19:28:28.149 4: FB_SIP[2376039], my parent is 1058279
2025.08.16 19:28:28.149 4: FB_SIP[2376039], using Leg.pm to find a free port
2025.08.16 19:28:28.164 4: FB_SIP[2376039], register new expire : 2025-08-16 19:33:28
2025.08.16 19:28:28.173 4: FB_SIP[2376039], CallStart with 1 files - first file : cache/17c5e5e7989d8c8c1ca8b9fb6436c960.alaw - PCMA/8000 , repeat 0
2025.08.16 19:28:28.175 4: FB_SIP[2376039], calling : TELEFONNUMMER
2025.08.16 19:28:31.906 4: FB_SIP[2376039], cb_final - status : OK
2025.08.16 19:28:31.906 4: FB_SIP[2376039], call established
2025.08.16 19:28:35.074 4: FB_SIP[2376039], Calltime : 3
2025.08.16 19:28:35.078 4: FB_SIP, CALLDone -> FB_SIP|1|ok|3
Den Test für ich in der Kommandozeile mit:

Code Auswählen Erweitern

set FB_SIP call TELEFONNUMMER 40 !Dies ist ein Testdurch.

Wer hat eine Idee? Wie kann ich ggf. weitere Tests durchführen?

Viele Grüße
Jürgen

[juemuc]

Hallo zusammen,

ich habe die Ursache gefunden. Ich nutze diverse VLANs und muss für die Kommunikation die notwendigen Ports freigeben.

Wenn ich alles freigebe funktioniert es. Jetzt muss ich "nur" noch wissen, welche Ports hier benötigt werden. Wer kann helfen?

Viele Grüße
Jürgen

[Flachzange]

Hallo zusammen,

ich habe die Ursache gefunden. Ich nutze diverse VLANs und muss für die Kommunikation die notwendigen Ports freigeben.

Wenn ich alles freigebe funktioniert es. Jetzt muss ich "nur" noch wissen, welche Ports hier benötigt werden. Wer kann helfen?

Viele Grüße
Jürgen

https://wiki.fhem.de/wiki/SIP-Client

Für VLANs musst Du aber keine Ports freigeben, sondern Routen einrichten. Es sei denn Du nutzt noch irgendo eine NAT dazwischen

[juemuc]

Problem gelöst!

Es mussten noch die relevanten RTP-Ports für UDP freigegeben werden.

@Flachzange: ohne Routing wurde das ganze VLAN-Konstrukt nicht funktionieren.

Viele Grüße
Jürgen 

Es waren natürlich die RTP-Ports und nicht RDP. Habe es oben im Text korrigiert.

[Flachzange]

Da hier gerade so schön viel Traffic ist, hänge ich mich mal dran

Ich habe letzte Woche meine Kubernetes-Umgebung auf Docker umgestellt (Migration von Truenas Scale). Danach habe ich festgestellt, dass ausgehende Anrufe oft in "calling" hängengleiben, obwohl der Anruf von der Gegenseite längst terminiert ist. Der Anruf bleibt in FHEM dauerhaft offen und wird nie geschlossen. Manchmal klappt es aber auch genau so wie erwartet und der Status geht auf Cancelled. Die grundsätzliche Signalisierung nach draußen funktioniert. Ich kann aber auch nicht genau sagen, ob es vor meiner Umstellung auch schon nicht sauber lief.

Ich habe darauf hin die komplette Kette von Firewall bis Container und zurück durchgearbeitet und wüsste jetzt nicht mehr, woran es noch scheiternn könnten:
- Outbound NAT mit statischer Port-Bindung
- Inbound NAT und entsprechende Firewall-Regeln
- Port-Weiterleitung in den Container

Ich habe mir dann die Pakete auf den jeweiligen Systemen (Firewall, Docker-Host, Container) angeschaut und es sieht alles richtig aus.

Im Container kommen die relevanten Pakete aus meiner Sicht an. tcpdump im Container selbst:

Code Auswählen Erweitern

15:14:26.524222 eth0  Out IP 172.16.5.2.9070 > 185.39.86.104.5060: SIP: REGISTER sip:sip.combert-swvelbert.de SIP/2.0
15:14:26.540435 eth0  In  IP 185.39.86.104.5060 > 172.16.5.2.9070: SIP: SIP/2.0 401 Unauthorized
15:14:26.545352 eth0  Out IP 172.16.5.2.9070 > 185.39.86.104.5060: SIP: REGISTER sip:sip.combert-swvelbert.de SIP/2.0
15:14:26.567842 eth0  In  IP 185.39.86.104.5060 > 172.16.5.2.9070: SIP: SIP/2.0 200 OK
15:14:26.572963 eth0  Out IP 172.16.5.2.9070 > 185.39.86.104.5060: SIP: REGISTER sip:sip.combert-swvelbert.de SIP/2.0
15:14:26.592910 eth0  In  IP 185.39.86.104.5060 > 172.16.5.2.9070: SIP: SIP/2.0 401 Unauthorized
15:14:26.597459 eth0  Out IP 172.16.5.2.9070 > 185.39.86.104.5060: SIP: REGISTER sip:sip.combert-swvelbert.de SIP/2.0
15:14:26.626127 eth0  In  IP 185.39.86.104.5060 > 172.16.5.2.9070: SIP: SIP/2.0 200 OK
15:14:26.651411 eth0  Out IP 172.16.5.2.9070 > 185.39.86.104.5060: SIP: INVITE sip:0175XXXXXX@sip.combert-swvelbert.de SIP/2.0
15:14:26.666935 eth0  In  IP 185.39.86.104.5060 > 172.16.5.2.9070: SIP: SIP/2.0 100 Trying
15:14:26.686626 eth0  In  IP 185.39.86.104.5060 > 172.16.5.2.9070: SIP: SIP/2.0 407 Proxy Authentication Required
15:14:26.691118 eth0  Out IP 172.16.5.2.9070 > 185.39.86.104.5060: SIP: ACK sip:0175XXXXXX@sip.combert-swvelbert.de SIP/2.0
15:14:27.424571 eth0  In  IP 185.39.86.104.5060 > 172.16.5.2.9070: SIP: OPTIONS sip:1247420@192.168.5.36:9070 SIP/2.0
15:14:31.479712 eth0  Out IP 172.16.5.2.9070 > 185.39.86.104.5060: SIP: INVITE sip:0175XXXXXX@sip.combert-swvelbert.de SIP/2.0
15:14:31.495325 eth0  In  IP 185.39.86.104.5060 > 172.16.5.2.9070: SIP: SIP/2.0 100 Trying
15:14:32.288327 eth0  In  IP 185.39.86.104.5060 > 172.16.5.2.9070: SIP: SIP/2.0 180 Ringing
15:14:34.390287 eth0  In  IP 185.39.86.104.5060 > 172.16.5.2.9070: SIP: SIP/2.0 486 Busy Here
15:14:34.862784 eth0  In  IP 185.39.86.104.5060 > 172.16.5.2.9070: SIP: SIP/2.0 486 Busy Here
15:14:35.862880 eth0  In  IP 185.39.86.104.5060 > 172.16.5.2.9070: SIP: SIP/2.0 486 Busy Here
15:14:37.862465 eth0  In  IP 185.39.86.104.5060 > 172.16.5.2.9070: SIP: SIP/2.0 486 Busy Here
Verbose-Log:

Code Auswählen Erweitern

025.08.17 15:14:26 4: mySIP, calling 0175XXXXXX, ringtime: 30 , no message
2025.08.17 15:14:26 4: mySIP, mySIP|0175XXXXXX|30||0
2025.08.17 15:14:26 4: mySIP, call -> mySIP|0175XXXXXX|30||0|0
2025.08.17 15:14:26 5: mySIP, call has pid 18067
2025.08.17 15:14:26 4: mySIP[18067], my parent is 10737
2025.08.17 15:14:26 4: mySIP[18067], trying to use port 9070
2025.08.17 15:14:26 4: mySIP[18067], register new expire : 2025-08-17 15:25:09
2025.08.17 15:14:26 4: mySIP[18067], CallStart DTMF : ABCD*#123--4567890
2025.08.17 15:14:26 4: mySIP[18067], calling : 0175XXXXXX
2025.08.17 15:14:26 5: mySIP, readingS:state Val:calling
2025.08.17 15:14:26 5: mySIP, readingS:call_state Val:calling 0175XXXXXX
2025.08.17 15:14:30 4: mySIP[18067], cb_final - Status : FAIL
2025.08.17 15:14:56 5: mySIP[18067], 0. Ende des ersten Loops
2025.08.17 15:14:56 5: mySIP[18067], 1. rtp_done : 0
2025.08.17 15:14:56 5: mySIP[18067], 2. fi : 0
2025.08.17 15:14:56 5: mySIP[18067], 4. timeout : 1
2025.08.17 15:14:56 5: mySIP[18067], 6. call_established : 0
2025.08.17 15:14:56 5: mySIP[18067], call->cancel

Schaue ich mir die Timestamps an, verstehe ich z.B. nicht, warum ein

Code Auswählen Erweitern

2025.08.17 15:14:30 4: mySIP[18067], cb_final - Status : FAIL
gesetzt wird. Zu diesem Zeitpunkt läuft ja gerade der Verbindungsaufbau.


Was darüber hinaus auffällig ist: Nachdem man einmal einen Call gemacht hat, ballert der Provider SIP Proxy auf dem selben Port die ganze Zeit OPTIONS-Pakete, auf die aber niemand mehr reagiert. Weil niemand antwortet, macht er das im 3-Sekunden-Takt. Unter anderem kommt ja genau eines während des Verbindungsaufbaus oben rein:

Code Auswählen Erweitern

15:14:27.424571 eth0  In  IP 185.39.86.104.5060 > 172.16.5.2.9070: SIP: OPTIONS sip:1247420@192.168.5.36:9070 SIP/2.0

Ich zerbreche mir da jetzt seit einem Tag den Kopf. Vielleicht hat ja jemand eine schlaue Idee oder genau den Fall schon mal gesehen. Es wirkt leider alles sehr undeterministisch. Wenn man denkt es funktioniert, klappt es 2 Minuten später nicht mehr. Was eigentlich auch immer sauber funktionierte: Anruf annehmen und dann auflegen. Aber auch das ist jetzt gerade nicht mehr garantiert.

[Elektrolurch]

Welche Fritzbox mit welchem OS? Da hatte sich nämlich das Verhalten (s.o.) beim Update der HW geändert.

[Flachzange]

Keine Fritzbox. Opnsense Firewall. Der SIP-Client meldet sich direkt beim Provider-Registrar.

[juemuc]

Kannst Du eventuell eine VM erstellen und dort FHEM ohne Docker installieren?

Ich nutze eine VM für mein FHEM-Testsystem, da ich mit Docker immer wieder Probleme hatte.