[gelöst] SIP in Verbindung mit Text2Speech

[matrois]

Hallo Forum,
ich bin Anfänger in Sachen SIP in Verbindung mit Text2Speech. Ich nutze eine Fritzbox 7490 (Firmware 7.11) als SIP Registrar. Auf der Fritzbox ist unter Telefonie ein Telefoniegerät eingerichtet, der SIP User ist fhem-sip. FHEM läuft im Dockercontainer, alle unter https://wiki.fhem.de/wiki/SIP-Client und https://wiki.fhem.de/wiki/Text2Speech beschriebenen Abhängigkeiten sind verfügbar. In FHEM habe ich nach einem update das Modul Text2Speech definiert.

Code Auswählen Erweitern

define T2S text2speech none
attr TTS_Language Deutsch
attr TTS_MplayerCall /usr/bin/mplayer
attr TTS_UseMP3Wrap 1
attr room System
attr verbose 4


Die Definition des SIP Moduls sieht wie folgt aus

Code Auswählen Erweitern

define SIP SIP
attr T2S_Device T2S
attr audio_converter ffmpeg
attr history_file ./log/SIP.sip
attr history_size 0
attr room System
attr sip_dtmf_loop once
attr sip_dtmf_send audio
attr sip_dtmf_size 2
attr sip_elbc yes
attr sip_from sip:fhem-sip@fritz.box
attr sip_ip 172.29.8.8
attr sip_listen dtmf
attr sip_registrar fritz.box
attr sip_ringtime 3
attr sip_user fhem-sip


Ein

Code Auswählen Erweitern

set SIP call <nummer> 30 !Test führt dazu, dass unter /opt/fhem/cache zwei Audiodateien (alaw und mp3) mit dem Text "Test" angelegt werden und ein Anruf an <nummer> durchgeführt wird. Wenn ich allerdings bei <nummer> rangehe wird nicht wie erwartet die Audiodatei abgespielt, sondern sofort aufgelegt. Ich habe bereits unter anderem versucht die Datei direkt auszuwählen:

Code Auswählen Erweitern

set SIP call <nummer> 30 /opt/fhem/cache/98743987543987....alaw führt zum gleichen Ergebnis. Ich komme irgendwie nicht weiter. Hat jemand einen Tipp für mich?

[Wzut]

Tipp 1 : warum postet du hier und nicht im passenden Modul Fred -> https://forum.fhem.de/index.php/topic,67443.0.html ?
Tipp 2 : bei SIP & Docker sind ein paar Dinge zu beachten , auch das wurde im Modul Thread schon diskutiert
Tipp 3 : ohne ein verbose 5 Log wird das zum Ratespiel

[matrois]

Vielen Dank für die Tipps.

Zu Tipp 1: Ich wollte dieser Regel (

https://forum.fhem.de/index.php/topic,65033.msg329997.html#msg329997) folgend im Zweifelsfall das Board "Anfängerfragen" nutzen. Wenn jede Frage (ggf. auch doppelt gestellte Fragen) alle an einen Thread zu dem Modul angehängt werden, ist der Modulthread am Ende etwas unübersichtlich. Dies vor allem weil ich keine Möglichkeit kenne gezielt einen Thread zu durchsuchen. Falls ich damit falsch liege stellt sich die Frage ob dieser Thread irgendwie an den Modulthread angehängt werden kann.

Zu Tipp 2: Aufgrund des Hinweises zu bereits behandelten Problemen im Zusammenhang mit Docker und SIP habe ich ein "TestFHEM" auf einem Raspi aktiviert. Dort habe ich ohne die Nutzung von Docker festgestellt, dass alles wie erwartet läuft. Dadurch kann m.M.n. das Problem auf die Nutzung von Docker eingegrenzt werden. Den Modulthread hatte ich vorher schon durchgearbeitet und z.B. eine Portfreigabe von 5060 bei dem Container eingerichtet. Zusätzlich zu Port 5060 habe ich auch Port 5070 freigegeben.
Aufgrund des Tipps habe ich über die Forensuche versucht die entsprechenden Stellen im Thread zu finden. Die Suchbegriffe "SIP" und "Docker" liefern für das gesamte Forum allerdings nur diesen Thread und eine einzige Fundstelle im Modulthread. Falls mir Infos zu der Forensuchfunktion selber fehlen, bitte haut sie mir um die Ohren. Ich habe mir schon des öfteren eine Funktion zur Anzeige aller Fundstellen innerhalb eines Threads gewünscht (ala suche nach "Docker" innerhalb vom Modulthread "SIP"). Denn dann wäre auch das Argument "unübersichtlich" (siehe zu Tipp 1) nichtig.

Trotz des Suchergebnisses der automatischen Suchfunktion weiß ich, dass "Docker" öfter im Modulthread vorkommt und liste hier für Nachfolgende meine Fundstellen (Googlesuche missbraucht: "inurl:https://forum.fhem.de/index.php/topic,67443 docker").

• #683: Ports sind zu öffnen und IP Adresse des Containers ist anzugeben (https://forum.fhem.de/index.php/topic,67443.msg827024.html#msg827024)
• #763: Port 5070 sollte auch geöffnet werden (https://forum.fhem.de/index.php/topic,67443.msg872141.html#msg872141)
• #650: IP des Wirtrechners eintragen (https://forum.fhem.de/index.php/topic,67443.msg817691.html#msg817691)
• #653: IP des Containers eintragen und procps und Net::SIP nachinstallieren (https://forum.fhem.de/index.php/topic,67443.msg818216.html#msg818216)
• #642: sip_ip ist erforderlich, angegebener Link führt ins Leere, der richtige Link (https://wiki.fhem.de/wiki/SIP-Client) ist nur der Link zu dem hier besprochenen Modul (https://forum.fhem.de/index.php/topic,67443.msg817362.html#msg817362) weitere Antworten deuten darauf hin, dass die IP des Wirtrechners beim Attribut sip_ip erforderlich ist (siehe #650)

[li]#314: Feststellung der IP des Containers, IP des Containers erforderlich (https://forum.fhem.de/index.php/topic,67443.msg676174.html#msg676174)
[/li][/list]

Teilweise widersprechen sich die Angaben stark (IP Wirtrechner oder Container für sip_ip erforderlich?). Von der Logik her müsste es die IP des Wirtrechners sein, da Fritzbox als SIP Registrar die IP des Containers ggf. nicht kennt. Also probiere ich das nochmal aus. Mit der IP des Wirtrechners als sip_ip bekomme ich die Fehlermeldung

Code Auswählen Erweitern

ListenRegister: can't open port 5070 at 192.168.0.222 : Cannot assign requested address
Der Port 5070 ist aber für den FHEM Container freigegeben. Hier komme ich leider nicht weiter.
Ein "netstat | grep 5070" auf dem Wirtrechner liefert null.


Zu Tipp3: Ich habe verbose auf 5 gesetzt (vor Änderung von sip_ip, siehe oben). Nach einem weiteren Testanruf mittels

Code Auswählen Erweitern

set SIP call **610 30 !Testanruf
zeigt das LOG

Code Auswählen Erweitern

2019.07.13 15:38:48 4: SIP, listen process 20011 must be killed befor we start a new call !
2019.07.13 15:38:48 1: Timeout for SIP_ListenStart reached, terminated process 20011
2019.07.13 15:38:48 5: SIP, MD5: Testanruf -> fc733508def35223568795cf3c48b357.mp3
2019.07.13 15:38:48 5: SIP, set call new -> SIP call **611 30 cache/fc733508def35223568795cf3c48b357.mp3
2019.07.13 15:38:48 4: SIP, audio file cache/fc733508def35223568795cf3c48b357.mp3 found
2019.07.13 15:38:48 5: SIP, not converted - using cache/fc733508def35223568795cf3c48b357.alaw from cache
2019.07.13 15:38:48 4: SIP, SIP|**611|30|cache/fc733508def35223568795cf3c48b357.alaw|0
2019.07.13 15:38:48 4: SIP, call -> SIP|**611|30|cache/fc733508def35223568795cf3c48b357.alaw|0|0
2019.07.13 15:38:48 5: SIP, call has pid 22368
2019.07.13 15:38:48 4: SIP[22368], my parent is 174
2019.07.13 15:38:48 4: SIP[22368], trying to use port 5070
2019.07.13 15:38:48 4: SIP[22368], register new expire : 2019-07-13 15:43:48
2019.07.13 15:38:48 5: SIP, readingB:state Val:calling
2019.07.13 15:38:48 5: SIP, readingB:listen_alive Val:22368
2019.07.13 15:38:48 5: SIP, readingB:expire Val:300
2019.07.13 15:38:48 4: SIP[22368], CallStart with 1 files - first file : cache/fc733508def35223568795cf3c48b357.alaw - PCMA/8000 , repeat 0
2019.07.13 15:38:48 4: SIP[22368], calling : **611
2019.07.13 15:38:48 5: SIP, readingS:call_state Val:calling **611
2019.07.13 15:38:48 4: SIP[22368], cb_final - status : FAIL - final : 481
2019.07.13 15:38:48 5: SIP, readingS:call_state Val:ringing
2019.07.13 15:38:54 4: SIP[22368], cb_final - status : OK
2019.07.13 15:38:54 4: SIP[22368], call established
2019.07.13 15:38:54 5: SIP, readingS:call_state Val:established
2019.07.13 15:38:55 5: SIP[22368], 0. Ende des ersten Loops
2019.07.13 15:38:55 5: SIP[22368], 1. rtp_done : Net::SIP::Simple::Call=HASH(0x55a4f1856f40)
2019.07.13 15:38:55 5: SIP[22368], 2. fi : 0
2019.07.13 15:38:55 5: SIP[22368], 4. timeout : 0
2019.07.13 15:38:55 5: SIP[22368], 6. call_established : 1
2019.07.13 15:38:55 5: SIP[22368], call->bye
2019.07.13 15:38:55 5: SIP[22368], RTP done : Net::SIP::Simple::Call=HASH(0x55a4f1856f40)
2019.07.13 15:38:55 5: SIP[22368], Timeout  : 0
2019.07.13 15:38:55 5: SIP[22368], while    : 0
2019.07.13 15:38:55 5: SIP[22368], Status   : OK
2019.07.13 15:38:55 4: SIP[22368], Calltime : 1
2019.07.13 15:38:55 4: SIP, CALLDone -> SIP|1|ok|1
2019.07.13 15:38:55 5: SIP, fifo is empty
2019.07.13 15:38:55 4: SIP, try restarting listen process after call ends
2019.07.13 15:38:55 4: SIP, Listen new PID : 22613
2019.07.13 15:38:55 4: SIP[22613], my parent is 174
2019.07.13 15:38:55 4: SIP[22613], trying to use port 5060
2019.07.13 15:38:55 4: SIP[22613], register new expire : 2019-07-13 15:43:55
2019.07.13 15:38:55 5: SIP, readingB:state Val:listen_dtmf
2019.07.13 15:38:55 5: SIP, readingB:listen_alive Val:22613
2019.07.13 15:38:55 5: SIP, readingB:expire Val:300

Auf dem Fritzfon klingelt es, nachdem man rangeht wird sofort aufgelegt. Bei gleicher Vorgehensweise am Raspberry (ohne Docker) wird die Ansage abgespielt. Die Datei "cache/fc733508def35223568795cf3c48b357.alaw" wird auch bei Nutzung von Docker erstellt, so dass ich davon ausgehe, dass es nicht am Text2Speech Modul liegt.

Falls jemand bis hier gelesen hat erstmal danke dafür. Außerdem danke für jeden weiteren Tipp.

[Wzut]

OK, ich kürze mal etwas ab :
a. von Doker habe ich selbst keine Ahnung , aber plin hat im SIP Thread bis jetzt den Leuten immer helfen können, u.A. hat er auch einen Abschnit dafür im Wiki ( https://wiki.fhem.de/wiki/SIP-Client ) geschrieben und er kann das Ganze bei sich nachstellen. Ich schreib ihn mal an, er antwortet normalerweise recht schnell, wenn man im richtigen Fred postet, denn da werden wir beide sofort benachrichtigt. Das ich das hier gesehen habe war reiner Zufall

b. Stell dich auf den ersten Post im SIP Thread und gib dann oben rechts im Suchfeld "Ports" ein , du erhälst 24 Treffer aus dem Thread wovon einige Docker betreffen und für dich interessant sein dürften/könnten.

c . u.A. ergibt die Suche bei Treffer #12 einen Hinweis auf RTP -> https://forum.fhem.de/index.php/topic,67443.msg802980/topicseen.html#msg802980
Und genau hier vermute ich dein Problem, denn das passt auch zu deinem geposteten Log : Das Telefon klingelt und als dann die RTP Verbindung aufgebaut werden soll um die Audio Datei zu übertragen, scheitert dies, d.h. kein Text2Speech Problem !
Versuch doch bitte zuerst die ganz einfache Variante :
1. setze sip_listen auf none , denn du willst anrufen nicht angerufen werden
2. versuche nur "set SIP call **610" , hier wird bei der Ruf Annahme eine Folge von DTMF Tönen angespielt. Auch das erfordert eine RTP Verbindung.
Hörst du die Tonfolge stimmt meine RTP Theorie wohl doch nicht. 

[matrois]

Sehr vielen Dank für die Antwort.

Ich habe zuerst auf "sip_listen none" umgestellt und ein

Code Auswählen Erweitern

set SIP call **610 abgesetzt. Ich habe keine Töne gehört und es wurde nach ein paar Sekunden erst aufgelegt. Deine Theorie mit RTP scheint also zu passen.

Dem Hinweis bei Treffer #12 folgend habe ich "$RTP_MAX_PORT = 2019;" gesetzt und danach für den FHEM Container alle Ports von 2000-2019 freigegeben. Zusätzlich habe ich die Ports 5080 (5080 wurde auch im SIP Thread erwähnt) und 7072 (7072 wird im Docker Abschnitt vom SIP Wiki erwähnt, ich dachte es wäre nur für Telnet?) für den FHEM Container geöffnet. Leider ändert sich dadurch nichts, es kommt immer noch kein einziger Ton raus. Ich finde es irgendwie unlogisch, dass die SIP Anmeldung nur mit der internen Container IP (172.29.8.5) funktioniert. Denn diese IP ist außerhalb des Wirtrechners unbekannt. Die Portfreigaben beziehen sich auf die IP des Wirtrechners (192.168.0.222). Mit der IP des Wirtrechners funktioniert allerdings die SIP Anmeldung nicht (und auch nichts anderes).

Ich habe mehrfach gecheckt ob die Ports des FHEM Containers frei sind. 5060,5070 und 5080 sind definitiv frei. Aber mit der IP des Wirtrechners (192.168.0.222) bekomme ich trotzdem die Fehlermeldung

Code Auswählen Erweitern

ListenRegister: can't open port 5070 at 192.168.0.222 : Cannot assign requested address
Ich befürchte da liegt auch noch was im Argen.

Kann evtl. jemand bestätigen ob man bei Docker unter sip_ip die Adresse des Containers oder die Adresse des Wirtrechners eingeben muss? Die Angaben im Forum widersprechen sich dahingehend leider. Das Wiki macht hierzu eigentlich eine klare Angabe (Angabe IP Docker Container). Dies verstehe ich irgendwie nicht, da der SIP Registrar die IP des Docker Containers nicht kennen kann.

Wenn ich wie im Wiki empfohlen die IP des Containers als SIP IP eingebe, dann dauert der Anruf auch deutlich länger (so als wollte er mir etwas sagen, aber es ist nicht hörbar )

Das Log sagt dazu folgendes:

Code Auswählen Erweitern


2019.07.13 21:07:55 4: SIP, Listen new PID : 932
2019.07.13 21:07:55 4: SIP[932], my parent is 167
2019.07.13 21:07:55 4: SIP[932], trying to use port 5060
2019.07.13 21:07:56 4: SIP[932], register new expire : 2019-07-13 21:12:56
2019.07.13 21:07:57 5: SIP, readingB:state Val:listen_dtmf
2019.07.13 21:07:57 5: SIP, readingB:listen_alive Val:932
2019.07.13 21:07:57 5: SIP, readingB:expire Val:300
2019.07.13 21:08:36 4: SIP, listen process 932 must be killed befor we start a new call !
2019.07.13 21:08:36 1: Timeout for SIP_ListenStart reached, terminated process 932
2019.07.13 21:08:36 4: SIP, calling **611, ringtime: 30 , no message
2019.07.13 21:08:36 4: SIP, SIP|**611|30||0
2019.07.13 21:08:36 4: SIP, call -> SIP|**611|30||0|0
2019.07.13 21:08:36 5: SIP, call has pid 1856
2019.07.13 21:08:36 4: SIP[1856], my parent is 167
2019.07.13 21:08:36 4: SIP[1856], trying to use port 5070
2019.07.13 21:08:36 4: SIP[1856], register new expire : 2019-07-13 21:13:36
2019.07.13 21:08:36 5: SIP, readingB:state Val:calling
2019.07.13 21:08:36 5: SIP, readingB:listen_alive Val:1856
2019.07.13 21:08:36 5: SIP, readingB:expire Val:300
2019.07.13 21:08:36 4: SIP[1856], CallStart DTMF : ABCD*#123--4567890
2019.07.13 21:08:36 4: SIP[1856], calling : **611
2019.07.13 21:08:36 5: SIP, readingS:call_state Val:calling **611
2019.07.13 21:08:42 4: SIP[1856], cb_final - Status : OK
2019.07.13 21:08:42 4: SIP[1856], call established
2019.07.13 21:08:42 5: SIP, readingS:call_state Val:established


[plin]

Hi,

>FHEM läuft im Dockercontainer,
Auf welchem Trägersystem? Welches OS?

>Das Wiki macht hierzu eigentlich eine klare Angabe (Angabe IP Docker Container). Dies verstehe ich irgendwie nicht, da der SIP Registrar die IP des Docker Containers nicht kennen kann.
Das perl-Modul will auf dem lokalen System einen Port als Listener öffen. Das kann nur der Container sein, weil das Modul im Container keinerlei Rechte im Wirtssystem hat. Die Erreichbarkeit von außen wird über die Optionen (Port-Mapping) im docker run sicher gestellt.

Wie sieht dein docker-Statement aus mit dem Du den Container startest?

Ciao, plin

[matrois]

Danke für die Unterstützung.

Docker (und damit auch der FHEM Container) läuft auf einem NAS (QNAP TS453Pro). Bei dem OS (QNAP OS / Firmware) handelt es sich um ein Embedded Linux.

Mit der Erklärung verstehe ich jetzt, dass es doch definitiv die Container IP sein muss. Mit der Container IP funktioniert aktuell die Anmeldung und es werden Anrufe abgesetzt. Es sind halt nur keine Töne zu hören.

Ich starte meine Container nicht über docker-statements sondern über docker-compose.

Mein docker-compose.yml sieht für den FHEM Container so aus:

Code Auswählen Erweitern

    fhem:
        build: './fhem/' 
        container_name: qnap_fhem
        hostname: qnap_fhem
        ports:
            - "8083:8083"
            - "8084:8084"
            - "8085:8085"
            - "1883:1883"
            - "5060:5060"
            - "5070:5070"
            - "5080:5080"
            - "2000:2000"
            - "2001:2001"
            - "2002:2002"
            - "2003:2003"
            - "2004:2004"
            - "2005:2005"
            - "2006:2006"
            - "2007:2007"
            - "2008:2008"
            - "2009:2009"
            - "2010:2010"
            - "2011:2011"
            - "2012:2012"
            - "2013:2013"
            - "2014:2014"
            - "2015:2015"
            - "2016:2016"
            - "2017:2017"
            - "2018:2018"
            - "2019:2019"           
        volumes:
            - /share/config/perm/fhem/opt-fhem/:/opt/fhem/
            - /share/backup/_fhem/:/share/backup/_fhem/
        environment:
            - CONFIGTYPE=configDB
        networks:
            - backend
        restart: unless-stopped

Das entsprechende Dockerfile

Code Auswählen Erweitern

FROM fhem/fhem:latest
# ab hier alles nur zum Testen, teilweise sind die Module im Image schon vorhanden...
RUN apt-get -y update; \
    apt-get -y upgrade;
RUN cpan install Net::SIP
RUN cpan install Text::Iconv
RUN apt-get install nano

Aufgrund der configDB Konfiguration greift der FHEM Container auf einen weiteren Container mit MySQL zu.

[Wzut]

du kannst aber auch mal RTP in die andere Richtung testen :
stelle sip_listen auf echo , dann ruf dein FHEM an und sobald das Modul den Ruf angenommen hat sage etwas.
Hörst du deine eigene Stimme als Echo ?

[matrois]

Ich habe das Attribut sip_listen von none auf echo umgestellt und dann die interne Nummer von fhem-sip (**621) von einem Fritzfon angerufen. Das war ein endloser Anruf (Gegenseite legt nicht auf). Es kam kein Echo zurück (was auch immer ich erzählt habe, auf der Gegenseite herrscht Totenstille).

[plin]

ok, das wird etwas komplizierter. Ich habe mir das aktuellste docker image mittels
docker pull fhem/fhem
runter geladen und dann ein SIP-Device angelegt. Es erscheinen aber Fehlermeldungen

Code Auswählen Erweitern

2019.07.14 18:42:44.328 1: usb create end
2019.07.14 18:42:44.329 0: Featurelevel: 5.9
2019.07.14 18:42:44.329 0: Server started with 11 defined entities (fhem.pl:19805/2019-07-09 perl:5.028001 os:linux user:fhem pid:220)
2019.07.14 18:43:05.784 1: PERL WARNING: Use of uninitialized value in subroutine entry at ./FHEM/96_SIP.pm line 143.
2019.07.14 18:43:05.784 2: SipTest, please check your FQDN hostname -> Bad arg length for Socket::inet_ntoa, length is 0, should be 4 at ./FHEM/96_SIP.pm line 143.

2019.07.14 18:43:57.511 1: MKDIR restoreDir/save/2019-07-14
sh: 1: ps: not found
2019.07.14 18:44:07.454 1: SipTest[1741], can´t find my parent 220 in process list !
Died at ./FHEM/96_SIP.pm line 386.


Also muss ich meine FHEM-Instanz erst mal läuffähig kriegen ...

[matrois]

Die erste Fehlermeldung um Zeile 143 hat etwas mit dem Hostnamen des Containers zu tun. Docker vergibt normalerweise ziemlich lange kryptische Hostnamen. Bei Dir scheint er den Hostnamen nicht zu finden. Selber kann man beim docker statement einen Hostnamen vorgeben.

Code Auswählen Erweitern

docker run --hostname siptest -p 7072:7072 -p 8083:8083 -p 5060-5080:5060-5080 -p 2000-2019:2000-2019 fhem/fhem

Die Änderung in der Datei /usr/share/perl5/Net/SIP/Util.pm habe ich manuell über nano gemacht (sed Befehl probiere ich gerade noch rum).

Code Auswählen Erweitern


apt-get update
apt-get install nano
nano -x /usr/share/perl5/Net/SIP/Util.pm


Änderung in nano

Code Auswählen Erweitern

$RTP_MAX_PORT = 2019;

Nachtrag01:
sed Befehl für Dockerfile

Code Auswählen Erweitern


RUN sed -i 's/our \$RTP_MAX_PORT = 12000\;/our \$RTP_MAX_PORT = 2019\;/g' /usr/share/perl5/Net/SIP/Util.pm


Nachtrag02:
Damit wir komplett auf gleichem Stand sind ist das mein Dockerfile

Code Auswählen Erweitern


FROM fhem/fhem:latest
RUN apt-get -y update
RUN cpan install Net::SIP
RUN cpan install Text::Iconv
RUN apt-get install nano
RUN sed -i 's/our \$RTP_MAX_PORT = 12000\;/our \$RTP_MAX_PORT = 2019\;/g' /usr/share/perl5/Net/SIP/Util.pm


und das der Abschnitt aus docker-compose.yml

Code Auswählen Erweitern


    fhem:
        build: './fhem/' 
        container_name: qnap_fhem
        hostname: qnap_fhem
        ports:
            - "8083-8085:8083-8085"
            - "1883:1883"
            - "5060:5060"
            - "5070:5070"
            - "5080:5080"
            - "2000-2019:2000-2019"         
        volumes:
            - /share/config/perm/fhem/opt-fhem/:/opt/fhem/
            - /share/backup/_fhem/:/share/backup/_fhem/
        environment:
            - CONFIGTYPE=configDB
        networks:
            - backend
        restart: unless-stopped


Von den volumes ist /share/backup/_fhem zum Testen uninteressant, da es nur zu Backupzwecken genutzt wird. Unter /share/config/perm/fhem/opt-fhem/ liegt auf dem Wirtsystem die fhem Installation, die im Container unter /opt/fhem eingebunden wird.

[plin]

tja, ich habe folgenden Stand erreicht:

Ich habe einen
set SipTest call **622 30 /opt/fhem/cache/71ce4185214eb43202358604a63cdcab.alaw
abgesetzt und auf dem Wirtssystem (192.168.3.51) mittels tcpdump mitgeschnitten. 192.168.3.1 ist meine FB.

Code Auswählen Erweitern

19:23:39.459057 IP 192.168.3.51.5070 > 192.168.3.1.5060: SIP: REGISTER sip:192.168.3.1 SIP/2.0
19:23:39.462900 IP 192.168.3.1.5060 > 192.168.3.51.5070: SIP: SIP/2.0 401 Unauthorized
19:23:39.464997 IP 192.168.3.51.5070 > 192.168.3.1.5060: SIP: REGISTER sip:192.168.3.1 SIP/2.0
19:23:39.470150 IP 192.168.3.1.5060 > 192.168.3.51.5070: SIP: SIP/2.0 200 OK
19:23:39.482460 IP 192.168.3.51.5070 > 192.168.3.1.5060: SIP: REGISTER sip:192.168.3.1 SIP/2.0
19:23:39.486288 IP 192.168.3.1.5060 > 192.168.3.51.5070: SIP: SIP/2.0 401 Unauthorized
19:23:39.488506 IP 192.168.3.51.5070 > 192.168.3.1.5060: SIP: REGISTER sip:192.168.3.1 SIP/2.0
19:23:39.493620 IP 192.168.3.1.5060 > 192.168.3.51.5070: SIP: SIP/2.0 200 OK
19:23:39.496153 IP 192.168.3.51.5070 > 192.168.3.1.5060: SIP: INVITE sip:**622@192.168.3.1 SIP/2.0
19:23:39.500624 IP 192.168.3.1.5060 > 192.168.3.51.5070: SIP: SIP/2.0 401 Unauthorized
19:23:39.502446 IP 192.168.3.51.5070 > 192.168.3.1.5060: SIP: ACK sip:**622@192.168.3.1 SIP/2.0
19:23:39.503805 IP 192.168.3.51.5070 > 192.168.3.1.5060: SIP: INVITE sip:**622@192.168.3.1 SIP/2.0
19:23:39.522619 IP 192.168.3.1.5060 > 192.168.3.51.5070: SIP: SIP/2.0 100 Trying
19:23:39.549736 IP 192.168.3.1.5060 > 192.168.3.51.5070: SIP: SIP/2.0 183 Session Progress
19:23:44.168874 IP 192.168.3.1.5060 > 192.168.3.51.5070: SIP: SIP/2.0 200 OK
19:23:44.173744 IP 192.168.3.51.5070 > 192.168.3.1.5060: SIP: ACK sip:4FAD73958A871BD891329308DF8ED@192.168.3.1 SIP/2.0
19:23:44.174140 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.194526 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.209399 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.229415 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.249410 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.269410 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.289410 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.309410 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.329409 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.349344 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.369408 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.389403 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.409409 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.429411 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.449408 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.469315 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.489433 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.509335 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.529406 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.540236 ARP, Request who-has 192.168.3.1 tell 192.168.3.51, length 28
19:23:44.540609 ARP, Reply 192.168.3.1 is-at 08:96:d7:ac:b4:31, length 46
19:23:44.549402 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.569410 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.589410 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.609409 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.629410 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.649408 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.669408 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.689405 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.709408 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.729406 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.749409 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.769343 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.789371 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.809409 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.829404 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.849410 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.869356 IP 192.168.3.51.3032 > 192.168.3.1.7078: UDP, length 172
19:23:44.891282 IP 192.168.3.51.5070 > 192.168.3.1.5060: SIP: BYE sip:4FAD73958A871BD891329308DF8ED@192.168.3.1 SIP/2.0
19:23:44.900873 IP 192.168.3.1.5060 > 192.168.3.51.5070: SIP: SIP/2.0 200 OK


Auf meinem Pad habe ich den Anruf in der FritzFon App entgegengenommen. Der endete in unter 1 Sekunde.
Laut Wireshark wird ab 19:23:44.174140 nach dem ACK im RTP Protocol PCMA Payload übertragen. Ich höre in meiner FritzFon App aber auch nichts.

@wzut: Hast Du eine Idee?

VG plin

[Wzut]

@wzut: Hast Du eine Idee?

nicht so wirklich. Du hattest doch früher schon Docker erfolgreich am Start, ging da die Audio Übertragung ?
Intressant wäre noch der Inhalt der ganzen 172 Byte langen UDP Pakete, ist das in Summe die komplette Audio Datei ?
D.h. ist der Inhalt jedes Pakets unterschiedlich oder wird hier immer wieder versucht das Gleiche an die FB zu senden in der Hoffung irgend einer Antwort ?
Jetzt müsste man den gleichen Mittschnitt von einem "normalen" System haben.

[plin]

ok, ich hab's.

Ich habe auf meinem Wirtssystem eine FHEM-Instanz installiert. Die Call-Session zeigt folgenden Unterschied:

Code Auswählen Erweitern

...
18:22:11.926179 IP 192.168.3.1.5060 > 192.168.3.51.5060: SIP: SIP/2.0 200 OK
18:22:11.926958 IP 192.168.3.1.7082 > 192.168.3.51.6030: UDP, length 172
18:22:11.930777 IP 192.168.3.51.5060 > 192.168.3.1.5060: SIP: ACK sip:4FAD73958A871BD891329308DF8ED@192.168.3.1 SIP/2.0
18:22:11.931085 IP 192.168.3.51.6030 > 192.168.3.1.7082: UDP, length 172
18:22:11.946903 IP 192.168.3.1.7082 > 192.168.3.51.6030: UDP, length 172
18:22:11.947146 IP 192.168.3.51.6030 > 192.168.3.1.7082: UDP, length 172
18:22:11.966796 IP 192.168.3.51.6030 > 192.168.3.1.7082: UDP, length 172
18:22:11.966864 IP 192.168.3.1.7082 > 192.168.3.51.6030: UDP, length 172
18:22:11.986710 IP 192.168.3.51.6030 > 192.168.3.1.7082: UDP, length 172
...


Es gibt in der RTP-Phase also auch eine Rückantwort von der FB zum SIP-Device. Auf Verdacht habe ich mal in der FB eine statische IPV4-Route angelegt
172.17.0.0/16 via Gateway 192.168.3.51

Und schon funkionierts.

@matrois: Kannst Du das bitte bei Dir testen.

P.S. Das Ganze setzt wie schon beschrieben die Anpassung von Util.pm mit
our $RTP_MAX_PORT = 2019;
voraus.

VG plin

[matrois]

Danke für die Unterstützung.
Leider funktioniert es bei mir noch nicht.
Ich hoffe ich habe die Einstellungen an der Fritzbox richtig gesetzt.

Heimnetz -> Netzwerk -> statische Route
IPv4 Netzwerk 172.29.8.0 (Docker Netzwerk 172.29.8.*)
Gateway 192.168.0.222 (IP Wirtsystem = NAS)
Subnetmask 255.255.0.0

Zwei Testanrufe mit

Code Auswählen Erweitern

set SIP call 30 !Test
ergeben folgende Logeinträge:

Code Auswählen Erweitern


2019.07.15 21:18:03 4: SIP, listen process 21164 must be killed befor we start a new call !
2019.07.15 21:18:03 1: Timeout for SIP_ListenStart reached, terminated process 21164
2019.07.15 21:18:03 5: SIP, MD5: Test -> 15f3ee2c2bd4e05acae32c787e103a17.mp3
2019.07.15 21:18:03 5: SIP, set call new -> SIP call **611 30 cache/15f3ee2c2bd4e05acae32c787e103a17.mp3
2019.07.15 21:18:03 4: SIP, audio file cache/15f3ee2c2bd4e05acae32c787e103a17.mp3 found
2019.07.15 21:18:03 5: SIP, not converted - using cache/15f3ee2c2bd4e05acae32c787e103a17.alaw from cache
2019.07.15 21:18:03 4: SIP, SIP|**611|30|cache/15f3ee2c2bd4e05acae32c787e103a17.alaw|0
2019.07.15 21:18:03 4: SIP, call -> SIP|**611|30|cache/15f3ee2c2bd4e05acae32c787e103a17.alaw|0|0
2019.07.15 21:18:03 5: SIP, call has pid 3270
2019.07.15 21:18:03 4: SIP[3270], my parent is 174
2019.07.15 21:18:03 4: SIP[3270], trying to use port 5070
2019.07.15 21:18:04 4: SIP[3270], register new expire : 2019-07-15 21:23:04
2019.07.15 21:18:04 5: SIP, readingB:state Val:calling
2019.07.15 21:18:04 5: SIP, readingB:listen_alive Val:3270
2019.07.15 21:18:04 5: SIP, readingB:expire Val:300
2019.07.15 21:18:04 4: SIP[3270], CallStart with 2 files - first file : CODE(0x558e1276b0c0) - PCMA/8000 , repeat 0
2019.07.15 21:18:04 4: SIP[3270], calling : **611
2019.07.15 21:18:04 5: SIP, readingS:call_state Val:calling **611
2019.07.15 21:18:07 4: SIP[3270], cb_final - status : OK
2019.07.15 21:18:07 4: SIP[3270], call established
2019.07.15 21:18:07 5: SIP, readingS:call_state Val:established
2019.07.15 21:18:08 5: SIP[3270], 0. Ende des ersten Loops
2019.07.15 21:18:08 5: SIP[3270], 1. rtp_done : Net::SIP::Simple::Call=HASH(0x558e129e9a88)
2019.07.15 21:18:08 5: SIP[3270], 2. fi : 0
2019.07.15 21:18:08 5: SIP[3270], 4. timeout : 0
2019.07.15 21:18:08 5: SIP[3270], 6. call_established : 1
2019.07.15 21:18:08 4: SIP[3270], next file : cache/15f3ee2c2bd4e05acae32c787e103a17.alaw
2019.07.15 21:18:08 4: SIP[3270], cb_final - status : OK
2019.07.15 21:18:09 4: SIP[3270], loop rtp_done : Net::SIP::Simple::Call=HASH(0x558e129e9a88)
2019.07.15 21:18:09 5: SIP[3270], call->bye
2019.07.15 21:18:09 5: SIP[3270], RTP done : Net::SIP::Simple::Call=HASH(0x558e129e9a88)
2019.07.15 21:18:09 5: SIP[3270], Timeout  : 0
2019.07.15 21:18:09 5: SIP[3270], while    : 0
2019.07.15 21:18:09 5: SIP[3270], Status   : OK
2019.07.15 21:18:09 4: SIP[3270], Calltime : 1
2019.07.15 21:18:09 4: SIP, CALLDone -> SIP|1|ok|1
2019.07.15 21:18:09 2: SIP, history file ./log/SIP.sip, Error on reading ./log/SIP.sip from database!
2019.07.15 21:18:09 5: SIP, fifo is empty
2019.07.15 21:18:09 4: SIP, try restarting listen process after call ends
2019.07.15 21:18:09 4: SIP, Listen new PID : 3406
2019.07.15 21:18:09 4: SIP[3406], my parent is 174
2019.07.15 21:18:09 4: SIP[3406], trying to use port 5060
2019.07.15 21:18:09 4: SIP[3406], register new expire : 2019-07-15 21:23:09
2019.07.15 21:18:09 5: SIP, readingB:state Val:listen_echo
2019.07.15 21:18:09 5: SIP, readingB:listen_alive Val:3406
2019.07.15 21:18:09 5: SIP, readingB:expire Val:300
2019.07.15 21:18:40 4: SIP, listen process 3406 must be killed befor we start a new call !
2019.07.15 21:18:40 1: Timeout for SIP_ListenStart reached, terminated process 3406
2019.07.15 21:18:40 5: SIP, MD5: Test -> 15f3ee2c2bd4e05acae32c787e103a17.mp3
2019.07.15 21:18:40 5: SIP, set call new -> SIP call **611 30 cache/15f3ee2c2bd4e05acae32c787e103a17.mp3
2019.07.15 21:18:40 4: SIP, audio file cache/15f3ee2c2bd4e05acae32c787e103a17.mp3 found
2019.07.15 21:18:40 5: SIP, not converted - using cache/15f3ee2c2bd4e05acae32c787e103a17.alaw from cache
2019.07.15 21:18:40 4: SIP, SIP|**611|30|cache/15f3ee2c2bd4e05acae32c787e103a17.alaw|0
2019.07.15 21:18:40 4: SIP, call -> SIP|**611|30|cache/15f3ee2c2bd4e05acae32c787e103a17.alaw|0|0
2019.07.15 21:18:40 5: SIP, call has pid 4322
2019.07.15 21:18:40 4: SIP[4322], my parent is 174
2019.07.15 21:18:40 4: SIP[4322], trying to use port 5070
2019.07.15 21:18:41 4: SIP[4322], register new expire : 2019-07-15 21:23:41
2019.07.15 21:18:41 5: SIP, readingB:state Val:calling
2019.07.15 21:18:41 5: SIP, readingB:listen_alive Val:4322
2019.07.15 21:18:41 5: SIP, readingB:expire Val:300
2019.07.15 21:18:41 4: SIP[4322], CallStart with 2 files - first file : CODE(0x558e0f189460) - PCMA/8000 , repeat 0
2019.07.15 21:18:41 4: SIP[4322], calling : **611
2019.07.15 21:18:41 5: SIP, readingS:call_state Val:calling **611
2019.07.15 21:18:43 4: SIP[4322], cb_final - status : OK
2019.07.15 21:18:43 4: SIP[4322], call established
2019.07.15 21:18:43 5: SIP, readingS:call_state Val:established
2019.07.15 21:18:44 5: SIP[4322], 0. Ende des ersten Loops
2019.07.15 21:18:44 5: SIP[4322], 1. rtp_done : Net::SIP::Simple::Call=HASH(0x558e12a38978)
2019.07.15 21:18:44 5: SIP[4322], 2. fi : 0
2019.07.15 21:18:44 5: SIP[4322], 4. timeout : 0
2019.07.15 21:18:44 5: SIP[4322], 6. call_established : 1
2019.07.15 21:18:44 4: SIP[4322], next file : cache/15f3ee2c2bd4e05acae32c787e103a17.alaw
2019.07.15 21:18:44 4: SIP[4322], cb_final - status : OK
2019.07.15 21:18:45 4: SIP[4322], loop rtp_done : Net::SIP::Simple::Call=HASH(0x558e12a38978)
2019.07.15 21:18:45 5: SIP[4322], call->bye
2019.07.15 21:18:45 5: SIP[4322], RTP done : Net::SIP::Simple::Call=HASH(0x558e12a38978)
2019.07.15 21:18:45 5: SIP[4322], Timeout  : 0
2019.07.15 21:18:45 5: SIP[4322], while    : 0
2019.07.15 21:18:45 5: SIP[4322], Status   : OK
2019.07.15 21:18:45 4: SIP[4322], Calltime : 1
2019.07.15 21:18:45 4: SIP, CALLDone -> SIP|1|ok|1
2019.07.15 21:18:45 2: SIP, history file ./log/SIP.sip, Error on reading ./log/SIP.sip from database!
2019.07.15 21:18:45 5: SIP, fifo is empty
2019.07.15 21:18:45 4: SIP, try restarting listen process after call ends
2019.07.15 21:18:45 4: SIP, Listen new PID : 4431
2019.07.15 21:18:45 4: SIP[4431], my parent is 174
2019.07.15 21:18:45 4: SIP[4431], trying to use port 5060
2019.07.15 21:18:45 4: SIP[4431], register new expire : 2019-07-15 21:23:45
2019.07.15 21:18:45 5: SIP, readingB:state Val:listen_echo
2019.07.15 21:18:45 5: SIP, readingB:listen_alive Val:4431
2019.07.15 21:18:45 5: SIP, readingB:expire Val:300


Es ist kein Ton zu hören.

Nachtrag:
Ich habe jetzt einfach weiter rumprobiert... Zwischendurch habe ich den Container zu anderen Dockernetzwerken hinzugefügt, wieder rausgenommen, die statische Route verändert... Mit den oben schon aufgeschriebenen Einstellungen funktioniert es jetzt bei mir auch. Herzlichen Dank für die Hilfe.