Modul 96_SIP

[Wzut]

den Fehler 110 hatten wir hier schon öfters, das SIP Modul kann nicht mit der PBX reden. Bei den Docker Usern lag es immer an irgendwelchen Ports die von A nach B nicht durchkamen. Keine Ahnung wie das bei deiner VM ausschaut. Firewall in irgend einer Form ?
Du verwendest ja unterschiedliche Sub Netze ( 172.20.10.x & 172.20.16 ) , wer kümmert sich um das Routing zwischen den Netzen ?
Hattest vor deinem Umzug das auch schon auf einer VM laufen ? 

[Tobbi]

Hallo,

das Routing übernimmt eine Sophos Firewall.
Ich habe testweise die VM direkt in das gleiche Netz gehangen, wie die TK Anlage.
Also mit 172.20.16.x IP.

Jetzt bekomme ich nach dem call Befehl die Fehlermeldung ,,Can't open Port 5080 on 172.20.16.x"
Das ganze ist sehr merkwürdig weil ich nach Attribut den Port 5060 nutze.
Ändere ich diese Einstellung auf Port 5080 dann kommt die gleiche Meldung mit dem Hinweis dass Port 5100 nicht geöffnet werden kann.

Die Trennung der Netzte hatte ich vorher schon.
Fhem lief da aber noch auf einem Raspberry Pi.

Gruß Tobias

[Wzut]

Jetzt bekomme ich nach dem call Befehl die Fehlermeldung ,,Can't open Port 5080 on 172.20.16.x"
Das ganze ist sehr merkwürdig weil ich nach Attribut den Port 5060 nutze.

nein das ist nicht merkwürdig, es wird mehr als ein Port benötigt , das Attribut legt die Basis fest und dann geht es in 10er Schritten weiter.
Das ist aber erst der Anfang, sprich Rufaufbau. Wenn die Verbindung steht und es soll Audio übertragen werden kommt nochmal was dazu, hatten wir hier schon mal, das war irgendwo in den Tiefen von Net::SIP saublöd vergraben.
(@plin erinnerst dich noch an diese Monster Range ? den Punkt haben wir glaube ich auch nie im Wiki verewigt ? ) 

[plin]

(@plin erinnerst dich noch an diese Monster Range ? den Punkt haben wir glaube ich auch nie im Wiki verewigt ? )

Ich glaube indirekt haben wir's doch im Wiki verewigt, bei der Nutzung von docker:

Code Auswählen Erweitern

docker run -d -p 7072:7072 -p 8083:8083 -p 5060:5060 -p 5070:5070 -p 2000-2019:2000-2019 fhem/fhem
Da taucht noch eine Port-Range 2000-2019 auf.

[Wzut]

hmm IMHO war die aber im Urzustand größer und der User hatte sie auf unseren Rat verkleinert weil er nicht hunderte von Ports via Rule in seiner Firewall zuweisen wollte.
Ich setze mich heute Mittag nochmal hin und suche den Teil hier im Thread 

Edit : gefunden 17 Mai 2018 -> https://forum.fhem.de/index.php/topic,67443.msg802980.html#msg802980
Default ist UDP Port 2000 - 12000 für RTP

[bown]

Hi,

ich brauche leider etwas Unterstützung:

folgender Usecase:
1. SIP-Türsprechstelle klingelt auf allen internen Telefonen, funktioniert auch, allerdings werden interne Anrufe nicht geloggt in der Fritzbox.
2. Raspi mit SIP Modul, allerdings ohne T2S Modul soll Anrufsignalisierung der TFE (Gruppenruf) loggen und ggf. eine Pushover Nachricht senden.

Das Modul läuft soweit und macht auch das was es soll bis auf die Tatsache, dass Anrufe durch den raspi  nach 3 maligen ringing entgegen genommen werden und kurz bevor der Call durch den pi beendet wird, erhalte ich noch einen komischen Ton im Telefon.
sip_listen ist auf wfp gesetzt und ich hatte den state so verstanden, dass der pi nur "lauscht" und darauf wartet das man eine "action" ausführt. Irgendwie scheint der Pi hier selber tätig zu werden

Danke und Gruß Christ

[plin]

Hi,

ich brauche leider etwas Unterstützung:

folgender Usecase:
1. SIP-Türsprechstelle klingelt auf allen internen Telefonen, funktioniert auch, allerdings werden interne Anrufe nicht geloggt in der Fritzbox.
2. Raspi mit SIP Modul, allerdings ohne T2S Modul soll Anrufsignalisierung der TFE (Gruppenruf) loggen und ggf. eine Pushover Nachricht senden.

Das Modul läuft soweit und macht auch das was es soll bis auf die Tatsache, dass Anrufe durch den raspi  nach 3 maligen ringing entgegen genommen werden und kurz bevor der Call durch den pi beendet wird, erhalte ich noch einen komischen Ton im Telefon.
sip_listen ist auf wfp gesetzt und ich hatte den state so verstanden, dass der pi nur "lauscht" und darauf wartet das man eine "action" ausführt. Irgendwie scheint der Pi hier selber tätig zu werden

Danke und Gruß Christ

Wie fängst Du den Call ab bzw. erkennst ihn? Notify oder DOIF? Kannst Du uns den Command anlisten. Falls Du den Call mit 'fetch' annimmst wird das hinterlegte Audiofile abgespielt.

[Wzut]

ich habe da eher den Verdacht das er sip_waittime gesetzt hat :

sip_waittime
Maximale Wartezeit im Status listen_for_wfp bis das Gespräch automatisch angenommen wird.

aber wie so oft  : warum müssen wir raten , ist es so schwer ein list zu posten ?

[Tobbi]

hmm IMHO war die aber im Urzustand größer und der User hatte sie auf unseren Rat verkleinert weil er nicht hunderte von Ports via Rule in seiner Firewall zuweisen wollte.
Ich setze mich heute Mittag nochmal hin und suche den Teil hier im Thread 

Edit : gefunden 17 Mai 2018 -> https://forum.fhem.de/index.php/topic,67443.msg802980.html#msg802980
Default ist UDP Port 2000 - 12000 für RTP

Ich habe die letzten Tage noch einige Stellschrauben gedreht.
Es scheint tatsächlich Probleme mit dem Routing zwischen den Netzwerken zu geben.
So ganz bin ich dem Thema nicht auf die Schliche gekommen.
Es liegt aber wohl an der Netzwerkkonfiguration.

Gruß Tobias

[Wzut]

Es scheint tatsächlich Probleme mit dem Routing zwischen den Netzwerken zu geben.

OK, da must du mit deiner Firewall klar kommen , aber was macht das Port Thema ?

[plin]

Ich habe die letzten Tage noch einige Stellschrauben gedreht.
Es scheint tatsächlich Probleme mit dem Routing zwischen den Netzwerken zu geben.
So ganz bin ich dem Thema nicht auf die Schliche gekommen.
Es liegt aber wohl an der Netzwerkkonfiguration.

Gruß Tobias

Um das Problem auf der docker-Seite ein- bzw. auszugrenzen könntest Du den docker container mit der option --net=host statt expliziten Port-Freigaben starten. Dann siehst Du zumindest, ob's an dem Übergang in den container und den freigeschalteten Port-Ranges oder an der FW liegt.

[Tobbi]

OK, da must du mit deiner Firewall klar kommen , aber was macht das Port Thema ?

Ja das stimmt.

Es scheint so, als wenn iptables Problem mit den UDP Paketen gehabt hat. Also zumindest auf der Schnittstelle, die direkt zum TK Server gehen. Habe eine Ausnahme hinzugefügt und es klappte auf Anhieb.
Das vorherige Problem scheint in der Netzwerkfirewall zu liegen. Also Modul läuft wie aus der Vergangenheit bekannt.

@Plin: Danke für deinen Tipp. Ich nutze allerdings eine VMware Umgebung. Daher kommt der Tipp für mich leider nicht in Frage.
Wie zuvor schon erwähnt, schätze ich dass die Probleme in der Netzwerkfirewall liegen.

[bown]

Wie fängst Du den Call ab bzw. erkennst ihn? Notify oder DOIF? Kannst Du uns den Command anlisten. Falls Du den Call mit 'fetch' annimmst wird das hinterlegte Audiofile abgespielt.

Hi, noch habe ich kein notify oder DOIF gebaut. Darum sollte der Raspi doch noch keiner keinerlei Aktionen durchführen, oder?

Anbei ein List:

Code Auswählen Erweitern


Internals:
   FUUID      5e35ae1e-f33f-2825-987d-32a997d8d21297b4
   LPID       892
   NAME       mySIP
   NOTIFYDEV  global
   NR         160
   NTFY_ORDER 50-mySIP
   STATE      listen_wfp
   TYPE       SIP
   VERSION    V1.91 / 31.07.18
   callnr     015154705706
   forcecall  0
   repeat     0
   ringtime   30
   READINGS:
     2020-02-01 19:48:44   call            done
     2020-02-01 19:48:44   call_attempt    0
     2020-02-01 19:48:44   call_state      canceled
     2020-02-01 19:48:44   call_success    0
     2020-02-01 19:48:44   call_time       0
     2020-02-03 10:39:54   caller          none
     2020-02-03 10:39:54   caller_name     ---
     2020-02-03 10:39:54   caller_nr       ---
     2020-02-03 10:39:54   caller_state    hangup
     2020-02-03 10:39:54   caller_time     0
     2020-02-03 12:10:04   expire          300
     2020-02-03 12:10:04   listen_alive    892
     2020-02-03 12:10:04   state           listen_wfp
   helper:
     CALL_BYE   canceled
     CALL_ERROR 1
     CALL_NAME  unknown
     CALL_NR    done
     CALL_START 1580582923
     CALL_TIME  0
     CALL_TYPE  out
     LISTEN_PID:
       abortArg   
       abortFn   
       arg        mySIP
       bc_pid     19
       finishFn   SIP_ListenDone
       fn         SIP_ListenStart
       pid        892
       timeout   
Attributes:
   history_file ./log/mySIP.sip
   history_size 0
   sip_dtmf_loop once
   sip_dtmf_send audio
   sip_dtmf_size 2
   sip_elbc   yes
   sip_from   sip:raspiSIP@fritz.box
   sip_ip     192.168.0.150
   sip_listen wfp
   sip_registrar 192.168.0.1
   sip_ringtime 30
   sip_user   raspiSIP


[Wzut]

Darum sollte der Raspi doch noch keiner keinerlei Aktionen durchführen, oder?

eigentlich nein, aber du bist wie ich vermutet habe in die sip_waittime Falle getappt.
D.h. du hast es nicht gesetzt aber dann wird der default Wert von 10 Sekunden genommen.
Lösung : setzte sip_waittime auf einen hohen Wert wie z.B. 60 oder 120

[bown]

eigentlich nein, aber du bist wie ich vermutet habe in die sip_waittime Falle getappt.
D.h. du hast es nicht gesetzt aber dann wird der default Wert von 10 Sekunden genommen.
Lösung : setzte sip_waittime auf einen hohen Wert wie z.B. 60 oder 120

Vielen Dank für den Lösungsansatz! Ich werde die Werte verändern und testen.

Gruß Chris