FritzBox ankommende Anrufe werden sporadisch nicht signalisiert

[schnurgly]

Kann es sein, das die FB und Gigaset DX800 auf den gleichen Port (5060) horchen und dadurch im Konflikt stehen?

 

[chrsto]

Nein, wie ich bereits schrieb, handelt es sich bei VoIP Anschlüssen der Telekom ausschließlich um ausgehende Verbindungen, aus Sicht des Endgerätes.

Die Verbindung wird zum Telekom Server aufgebaut und muss gehalten werden. Eingehende Anrufe signalisiert die Telekom dann über diese offene Verbindung. Der lokale Port des Endgerätes ist erst mal zweitrangig, da es nicht horcht.

Auch die RTP Verbindung des ein-/ausgehenden Gesprächs wird vom Endgerät aufgebaut.

Die verwendeten Endgeräte benötigen dazu einen ungehinderten Zugang zum Internet. D.h. kein SIP ALG, kein Connection Tracker und bei manchen Routern ist es notwendig auf FullCone Nat umzustellen.

 

[ellerichb]

Das FullConeNAT ist dann aus Sicht der Fritz Box nur ausgehend erforderlich, oder?

 

[koyaanisqatsi]

Moinsen


Hinweis, ich weiss nicht ab welcher FRITZ!OS Version, aber mit 7.56 auf einer 7590 werden zufällige SIP Ports für die Anmeldung genutzt.
Also, wenn es 5060 für SIP sein muss (für Firewallregel), deaktiviere das...
<--<< Barrierefrei: Telefonie > Eigene Rufnummern > Anschlusseinstellungen
...ich finde diese Einstellung aber super (ohne vorgelagerte Router/Firewall), denn es gibt keine "Friendly-Scanner" mehr im SIP Log der Fritz!Box

 

[chrsto]

Das könnte eine Ursache sein, wenn in der Firewall als Quellport ein zu kleiner Bereich zugelassen wurde.

Korrektur: Stimmt nicht, dann würde die Registrierung komplett fehlschlagen und ausgehende Telefonate auch nicht funktionieren.

Die verwendeten Endgeräte benötigen dazu einen ungehinderten Zugang zum Internet.

 

[ellerichb]

Vollzitat gemäß Boardregeln https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ entfernt by stoney

Seitdem ich diesen Haken gesetzt habe, scheint es zu funktionieren.

Aber wie das mit nicht eindeutig zu reproduzierenden Fehlern so ist, werde ich morgen immer mal wieder testen, bevor ich Entwarnung gebe.

-- Zusammenführung Doppelpost gemäß Boardregeln https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ by stoney

Also das meine ich. Der Haken war vorher nicht gesetzt:

 

[KunterBunter]

Dann hast du wohl, obwohl vorher mehrfach geschrieben, das SIP ALG auf Port 5060 in deinem Securepoint-UTM nicht deaktiviert.

 

[ellerichb]

Vollzitat gemäß Boardregeln https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ entfernt by stoney

Aber selbstverständlich habe ich das. Und zwar exakt nach der Anleitung aus dem Securepoint-Wiki, die Du verlinkt hast.

 

[KunterBunter]

Dann scheint die Anleitung exakt so nicht zu funktionieren. Wende dich doch diesbezüglich einfach mal an den Hersteller.
Vorher mach mal ein debug kmod list und suche nach sip.

 

[chrsto]

Die angesprochene Option in der FritzBox dürfte wohl eher den genutzten Quellport der FritzBox betreffen. Eine zufällige Änderung des Zielports wäre sinnlos, da die SIP Plattform der Telekom nur auf Port 5060 bzw. 5061 lauscht.

Ein SIP ALG richtet sich aber nach dem gewählten Zielport. Wenn es also tatsächlich mit dem Aktivieren dieser Option läuft, dann ist kein SIP ALG involviert. Dieser müsste dann in jedes Datenpaket schauen und würde sich von einem zufällig gewählten Port nicht beeindrucken lassen.

 

[ellerichb]

Vollzitat gemäß Boardregeln https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ entfernt by stoney

Ich möchte natürlich nicht ausschließen, dass ich etwas in dem Securepoint-Wiki etwas falsch übernommen habe. ImZweifel kann ich, was die Securepoint-Seite betrifft, auch den Support in Anspruch nehmen, ich bin da Reseller.

Die SIP-Module und die betreffenden Conntrack-Module habe ich per

debug kmod unload module nf_nat_sip
debug kmod unload module nf_nat_h323
debug kmod unload module nf_conntrack_sip
debug kmod unload module nf_conntrack_h323

entladen.


Folglich tauchen die hier nicht mehr auf:

xt_FULLCONENAT
xt_nat
tun   
pppoe 
pppox 
af_packet
ppp_generic
slhc  
8021q 
garp  
mrp   
ip6table_mangle
ip6table_nat
ip6table_raw
xt_connmark
xt_mark
iptable_mangle
xt_MASQUERADE
xt_REDIRECT
xt_limit
xt_NFLOG
xt_policy
xt_set
xt_TCPMSS
xt_tcpudp
iptable_raw
tcp_diag
inet_diag
nfnetlink_log
nf_conntrack_netlink
bonding
br_netfilter
bridge
stp   
llc   
nf_nat_pptp
nf_conntrack_pptp
nf_nat_tftp
nf_conntrack_tftp
nf_nat_irc
nf_conntrack_irc
nf_nat_ftp
nf_conntrack_ftp
nf_nat_amanda
ts_kmp
nf_conntrack_amanda
ip_set_hash_netiface
ip_set_hash_net
ip_set_list_set
ip_set
nfnetlink
ip6t_rt
ip6table_filter
ip6_tables
ipt_REJECT
nf_reject_ipv4
xt_conntrack
iptable_nat
nf_nat
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
iptable_filter
ip_tables
x_tables
nf_log_syslog
i915  
ath9k 
ath9k_common
ath9k_hw
ath   
mac80211
intel_gtt
i2c_algo_bit
ttm   
drm_kms_helper
libarc4
syscopyarea
sysfillrect
sysimgblt
crc32_pclmul
crc32c_intel
fb_sys_fops
drm   
cfg80211
aesni_intel
crypto_simd
cryptd
rfkill
igb   
i2c_core
squashfs

-- Zusammenführung Doppelpost gemäß Boardregeln https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ by stoney

Vollzitat gemäß Boardregeln https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ entfernt by stoney

Ich verstehe Deine Argumentation.

Ich war überrascht, dass ein Häkchen, das einen Port randomisiert, zumindest scheinbar Abhilfe schafft. Hat aber irgendwie den Beigeschmack eines Workarounds. Ich würde es lieber verstehen und eine Lösung generieren.