manchmal keine ankommenden Anrufe (fritzbox als TK-Anlage)

Es gibt 77 Antworten in diesem Thema, welches 23.448 mal aufgerufen wurde. Der letzte Beitrag () ist von Weissbierschuettler.

    Zitat von bic

    So wie es ausschaut, verwendet meine 3CX doch zwei RTP-Ports

    Die 3CX nutzt immer 2 nebeneinanderliegende Ports und nimmt die willkürlich aus der Range 9000-10999.

    Danke 1

    Mit „Sollte Seuche“ meine ich das die RFC nicht wirklich bindend sind. Steht ja auch „SHOULD“


    Zitat

    Auch hier schau ich mal bei Gelegenheit, wie mein kleiner Bubble das handhabt (der leistet sich ja auch ein AON), vielleicht bin ich ja nur verwöhnt :winking_face_with_tongue:

    So, die Gelegenheit passte gerade:


    Vereinigte Stadtwerke ... Oft belächelt aber sehr oft sitzen genau da noch Menschen die es Interessiert

    und nicht „Millionen“ von Anschlüssen verwalten müssen. Und dann machen die auch noch AON

    (immer noch oder sind sie umgesattelt wenn die noch ausbauen)


    Hab nun keine Ahnung von der 3CX.

    Aber ja es sieht danach aus als wenn auf dem 9004 das Gespräch laufen könnte und der 9005 dann RTCP ist.


    Im Grunde müsst mann sich aber INVITE und den Response anschauen also genauer

    die SDP Header ob ein RTCP auch wirklich ausgehandelt wird oder da auch Daten drüber laufen.


    Könnt mir durchaus vorstellen das 3cx das versucht und Ressourcen dafür bereitstellt

    (den laut RFC soll es ja „RTP Port +1“ sein) und pauschal von sich sendet.

    Der Carrier das aber Ignoriert verfallen lässt, nicht annimmt und seinerseits nichts Sendet


    Aber wie gesagt, ohne auf Trace Level die Invites zu checken oder zu prüfen

    ob traffic in beide Richtungen fließt ist es schwer zu sagen.

    Kannst du ein SIP trace auf deiner Anlage durchführen. Der invite vom ankommenden Anruf des carriers

    müsste genug sein um Klarheit zu schaffen.


    Im SDP des INVITE gibt es dann das media Attribute „rtcp:portnummer“ ungefähr so:


    Wenn da vom Carrier nichts kommt... will er das auch nicht :smiling_face:

    Zitat von gierig

    Und dann machen die auch noch AON

    (immer noch oder sind sie umgesattelt wenn die noch ausbauen)

    Machen die immer noch und bauen auch weiter aus und haben hier schon in mehreren Landkreisen jede kleine Butze mit symetrischen FTTH versorgt:



    Zu Hause (auch nur ne kleine Butze) habe ich dies von denen schon seit ca. 10 Jahren (in den Büros noch nicht so lange) und bin extrem zufrieden, auch mit deren Service. Leider muss ich nun mit einem Büro umziehen und habe es da nun wieder mit den -wie schreibst Du- großen Bubbles zu tun --> Katastrophe. Hier (z.Z. im Büro) habe ich 600 Mbit/s gekauft (bis 1000/1000 wär möglich) und das ist das gerade aktuelle Ergebnis:



    Aber das nur so am Rande.


    An sonst:

    Zitat von gierig

    Kannst du ein SIP trace auf deiner Anlage durchführen.

    Werde ich einmal versuchen, bin ja selbst gespannt.

    Ich bin ja noch ein update schuldig...


    So weit funktioniert alles weiterhin problemlos.


    Aktuell sind testweise einige Nummern direkt im Gigaset konfiguriert und einige in der Fritzbox, funktionieren alle Problemlos parallel.


    Wird dann aber zukünftig nur im Gigaset laufen und wenn dann auch mal die Access Points auf Ubiquiti umgestellt sind fliegt die Fritze raus.


    Edit: achso, irgendwelche Portweiterleitungen sind nicht mehr aktiv.


    grüße und danke nochmal

    Hallo zusammen,


    auch wenn dieser Thread schon etwas älter ist scheint mein Thema hier rein zu passen.


    Ich habe Probleme die Internettelefonie per Fritz Fon App ans Laufen zu bekommen.


    Die Fritzbox hängt als reiner IP-Client für VOIP an meiner UDM Pro. VOIP ist in der Fritzbox konfiguriert und läuft grundsätzlich. Wir möchten als Telefon rein unsere Handys mit Fritz Fon App verwenden. Fritzbox und Handys sind im selben VLAN.


    Ausgehende Anrufe funktionieren problemlos. Eingehende Anrufe nur sporadisch. In der Regel dann, wenn kurz nach einem ausgehendem Anruf wieder raus telefoniert wird. Das war gestern auch der einzige Test den ich mehrfach wiederholt habe. Es scheint als wenn auch bei mir irgendwo ein Problem damit besteht die Anrufe von extern intern zur Fritzbox zu routen.


    In der FB habe ich die typischen Einstellungen gesetzt, inkl. dem Haken für Portweiterleitung offen halten auf 30 Sek. In der UDM habe ich schon diverse Dinge getestet. Folgendes ist aktuell eingerichtet:


    - Port Forwarding für Port 5060 und noch einen Port für STUN von WAN auf Fritzbox, eingeschränkt auf die Netze die der Anbieter Epcan für seine SIP Server beschreibt


    - Conntrack Modules: SIP rausgenommen

    - State timeouts für UDP Stream und UDP others auf 300 Sekunden gesetzt



    - Firewall Regeln für Internet und LAN für die vom Anbieter genannten Server, plus den, den ich bei Tcpdump sehe, gesetzt.



    Wie ich gelesen habe sollten Firewallregeln und Conntrack Modules eigentlich keine Rolle spielen. Es macht bisher auch keinen Unterschied ob ich diese Einstellungen gesetzt habe oder nicht.


    Folgende tcpdump Traces habe ich bekommen:


    Ausgehender Anruf - funktioniert immer

    Eingehender Anruf - direkt nach Auflegen des vorherigen Anrufes. Anruf erfolgt von dem zuvor angerufenem Mobilgerät. Hat funktioniert.

    Code
    root@UDM-pro:~# tcpdump -n -i ppp0 port 5060
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
20:44:49.194122 IP 130.255.125.86.5060 > 149.50.183.132.5060: SIP: INVITE sip:[email protected]:5060;uniq=FD399BB83F08E47670A3109ABD87EE0 SIP/2.0
20:44:49.229563 IP 149.50.183.132.5060 > 130.255.125.86.5060: SIP: SIP/2.0 100 Trying
20:44:49.257568 IP 149.50.183.132.5060 > 130.255.125.86.5060: SIP: SIP/2.0 180 Ringing
20:44:56.363051 IP 149.50.183.132.5060 > 130.255.125.86.5060: SIP: SIP/2.0 200 OK
20:44:56.639539 IP 130.255.125.86.5060 > 149.50.183.132.5060: SIP: ACK sip:[email protected]:5060;uniq=FD399BB83F08E47670A3109ABD87EE0 SIP/2.0
20:45:00.189810 IP 130.255.125.86.5060 > 149.50.183.132.5060: SIP: BYE sip:[email protected]:5060;uniq=FD399BB83F08E47670A3109ABD87EE0 SIP/2.0
20:45:00.210040 IP 149.50.183.132.5060 > 130.255.125.86.5060: SIP: SIP/2.0 200 OK

    Eingehender Anruf - kurze Zeit später. Wird nicht durchgestellt. Freizeichen aber es klingelt nichts

    Code
    root@UDM-pro:~# tcpdump -n -i ppp0 port 5060
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
20:46:08.712920 IP 130.255.125.86.5060 > 149.50.183.132.5060: SIP: INVITE sip:[email protected]:5060;uniq=FD399BB83F08E47670A3109ABD87EE0 SIP/2.0
20:46:08.750036 IP 149.50.183.132.5060 > 130.255.125.86.5060: SIP: SIP/2.0 100 Trying
20:46:08.760601 IP 149.50.183.132.5060 > 130.255.125.86.5060: SIP: SIP/2.0 180 Ringing

    Kann ich irgendwo erkennen ob das Thread Management etwas blockiert?


    Hier noch ein paar technische Informationen meines Anbieters.

    SIP-Trunk-Konfigurationshinweise_1-3.pdf


    Gurß

    René

    Zitat von Renek83

    Kann ich irgendwo erkennen ob das Thread Management etwas blockiert?

    das Thread Management ist nicht Dynamisches wenn es anschlägt und die Automatisiert was blockt dann siehst du eine

    Regeln in der Firewall einstellungen.



    Das verhalten bei ist eigentlich so typisch für NAT Timeouts die mit den

    Timeout hochsetzend und Verbidung offen halten sollten eigentlich behoben sein sollten.

    Du Könntest die UDP Timeouts zum testen nochmal Verdoppeln oder gleich auf 900.


    Wobei deine Weiterleitungen sollte das nicht nötig machen, die scheinen aber nicht zu greifen.



    Der Dump zeigt ja schonmal das ein Anruf ankommen will. Der Klopft also schon an

    das sind dann mit Outbound schon 80% Funktion :smiling_face:


    Kommen die Infixes den auf der FB an ?

    Das VLAN Interface heißt „brx“ (X mit der Vlan Nummer ersetzen)


    Oder


    Code
    apt update && apt install sngrep
sngrep

    snerp is ein mehr oder weniger mächtiger SIP Trauer der dann auch gleich alle Interface Captured...

    Zitat von gierig

    das Thread Management ist nicht Dynamisches wenn es anschlägt und die Automatisiert was blockt dann siehst du eine

    Regeln in der Firewall einstellungen.


    Wie meinst du das genau? Ist das Thread Managment nur aktiv wenn ich eine solche FW Regel sehe? Ich habe keine solche Regel, aber ich sehe auch keine Einträge unter System Log -> Security Detections. Dort hätte ich gedacht sehe ich auch wenn die FW eingehende Verbindungen blockieren würde.


    Sngrep habe ich schon mal installiert. Testen muss ich das heute Abend.

    Zitat von Renek83

    Dort hätte ich gedacht sehe ich auch wenn die FW eingehende Verbindungen blockieren würde.

    Siehst du auch.


    Was ich meine ist das das IPS nicht Dynamisch irgendwas block oder freigibt. Wenn Es was blockt gibt es ne Meldung

    und halt einen Eintrag in den Firewire rules um diesen ggf. Manuel wieder zu entfernen.


    Sprich wenn du keine IPS Rules und kein Log hast wird da auch nicht geblockt vom IPS

    Hier noch der Output (Extended bzw. Raw) von sngrep. Ich werde daraus nicht wirklich schlau.



    Es kommt erst dann ein Acknowledge wenn der AB rangeht.


    Wie kann ich prüfen ob die Invites bei der Fritzbox ankommen?

    Sollte so ersichtlich sein.

    sngrep -c (das -c ist nen filter auf nur Invites)


    Anruf von Extern.

    Erste Zeile ist der ankommende Anruf zur Anlage, hier halt von Telekom auf meine IP.

    Zweite Zeile is von der Anlage zu meinen SIP Phone (nur der Vollständigkeit halber)



    Geht man in den die Erste Zeile mit Enter ein und macht das rechte Detail Fenster Kleiner (0 und 9, ggf. F2 für ne Kompaktere Ansicht)



    Folgt die Ansicht, da alle Interface Erfasst werden kommt es hier evt doppel Darstellungen.

    Man erkennt aber sofort das Der call von Extern (217.0.147.13) die IP triff bzw eine Zeile weiter die Interne IP

    der TK Anlage. DIESE mus auch quasi direkt ein „100 Trying“ zurücksenden.


    GANZ Sicher sonst halt mit TCPDUMO nur auf den Interface in dem die Frizbox ist (z.B br0 für Default VLAN oder br99 für vlan 99)

    Persönlich würde ich mir den trace aber in ein File Schireben (-w) und mi Wireshark verwursten weil es einfach schöner

    ist Quell und Destination IP zu sehen.



    Code
    Aus deinem PDF:
Session-Timeout für UDP-Verbindungen muß auf mindestens 10 Minuten eingestellt werden,
sofern die Telefonanlage keinen Keep-Alive unterstützt

    Laut Screenshot oben hast du „300“ eingestellt was grade mal 5 min sind. Kommen wird also erstmal wider zu meinen ersten Tipp zurück.


    Zitat von gierig

    Du Könntest die UDP Timeouts zum testen nochmal Verdoppeln oder gleich auf 900.

    Wenn dein Carrier 600 Sekunden will würde ich ne schippe drauflegen und wirklich 900 (15 min) einstellen....

    Ich hatte es vorhin noch auf 600 Sekunden gestellt. Hatte nichts geändert. Sobald ich 1-2 Min warte nach dem ausgehenden Anruf, geht eingehend schon nichts mehr. Ich glaube daher nicht das es am Sessiontimeout liegt. Eigentlich sollte die Fritzbox ja auch schon alle 30 Sek. ein Keepalive schicken.


    Ich muss mir noch mal ein Dect Telefon besorgen. Würde mich interessieren ob es damit geht und es dann nur ein Problem bei Verwendung der Fritz Fon App gibt.

    Zitat von Renek83

    Ich hatte es vorhin noch auf 600 Sekunden gestellt. Hatte nichts geändert. Sobald ich 1-2 Min warte nach dem ausgehenden Anruf, geht eingehend schon nichts mehr. Ich glaube daher nicht das es am Sessiontimeout liegt

    Dann wohl eher nicht, wobei wenn du eh Statische Portweiterleitung hast sollte das eh kein Thema sein.

    Aber DU solltest auf jeden Fall im Trace im Netz der AVM box den ganzen traffic aus sehen können.


    Andere Dinge die mir in den sinn kommen:

    Andere Geräte die mit dem Carrier über den gleichen Port Kommunizieren ? (Bei UDP ist der Sende Port üblich dem Empfänger Port also 5060)

    Andere Geräte die evt. die gleiche Nummer Registrieren ? (Multi reg mag nicht jeder Provider)

    Der Trace hat mir noch nicht viel weitergeholfen. Auch hier sehe ich das der Anruf eingeht (192.168.1.147 ist die Fritzbox)



    Die Fritzbox meldet dann auch den Status Ringing zurück an den Anrufer, aber weiter sehe ich nichts im Trace. Ich erkenne jetzt nicht welche Daten gesendet werden um über Callkit die FritzFon App anzusprechen.


    Es gibt keine weiteren Geräte, die die Nummer registrieren. Sie ist nur auf der Fritzbox eingerichtet. Andere Geräte ide Port 5060 nutzen wären mir jetzt keine bekannt. Im Trace taucht der Port auch nur in Verbindung mit dem Anruf auf.

    Mhhh Seltsam.


    AVM bekommt den Invite (auch wenn als Fragmentiertes Paket), antworte auch mit dem 100 Trink und 180 Ring..

    Damit gehts dann weiter bis die Verbidung angenommen wurde (AVM würde nen 200 OK senden und carrier dann ein ACK)

    Damit „fühlt“ es sich an als wenn die Box einfach Klingeln. Wenn nicht auf dein Mobil teil ankommt...

    Handy mit der APP ist im gleichen VLAN wie die AVM Kiste ?


    Ohne die FritzAPP zu kennen (SmartPhones gabs noch. nicht das letze mal wo ich ne FB aktive benutzt habe)

    könnte ich mir vorstellen das die ärger macht wenn sie nicht im gleichen Netz ist wie die FB.


    Und du solltest ja wenn du die FB traced auch diesen traffic sehen der dann zu APP geht.

    Client (aktuell iPhone meiner Frau) ist im selben Netz. Testanruf von ihr ausgehend über FritzFon App geht auch. Das komische ist, ich habe ja wie im Screenshot zu sehen auf die IP der FB gefiltert. Da ist kein weiterer Traffic aufgezeichnet. Ich hätte erwartet das ich dort nun sehe das er eine Verbindung mit der Client IP aufbaut.


    Die 200 Ok und ACK Pakete sehe ich auch im sngrep Trace wenn ich warte bis der AB das Gespräch annimmt. Hab irgendwie das Gefühl die FB findet das Zielgerät mit der Fonapp nicht. Leider kann ich gerade vom remote nicht auf das Protokoll der FB schauen, falls da überhaupt etwas erscheint.


    Was ich auch komisch finde - ich habe jetzt noch mal einen Trace erstellt mit tcpdump -w sip.pcap, also ohne auf ein bestimmtes Interface eingeschränkt. Diesmal gewartet bis der AB rangeht. Komischerweise taucht im dem Trace nicht die IP der Fritzbox auf.



    --------------------------------------


    Habe gerade noch diesen Hinweis bei AVM gefunden. Das könnte noch passen. Wenn ich bei mir in die App schaue steht in der Einstellung aktuell WLAN-Funknetze: Fritz!Box 7490, das ist aber nur der Name der FB, nicht unsere WIFI SSID.



    So, kaum richtig eingerichtet funktioniert es auch :smiling_face:


    Muss man erst mal drauf kommen, dass diese App per Default meint man ist im Wlan der FB, obwohl diese gar kein Wlan ausstrahlt, sondern nur IP-Client ist.

    3 Mal editiert, zuletzt von Renek83 ()

    Danke 1
    Zitat von Renek83

    tcpdump -w sip.pcap, also ohne auf ein bestimmtes Interface eingeschränkt


    Code
    -i
--interface=interfaceListen, report the list of link-layer types, report the list of time stamp types, or report the results of compiling a filter expression on interface. If unspecified and if the -d flag is not given, tcpdump searches the system interface list for the lowest numbered, configured up interface (excluding loopback), which may turn out to be, for example, ``eth0''

    Sprich ohne Angabe vom Interface wird das erst beste genommen.


    Da Iphone... Private Relay an oder irgend ein VPN Tunnel Villeicht ?

    Danke, hatte das Manuel nicht gelesen. Das erklärt die Traces.


    Es funktioniert aber nun. Lag dann wohl bloß am falschen WLAN Namen in der Fritz Fon App.

    Habe nun auch noch zuvor gesetzte Einstellungen auf der Udm zurückgenommen. Upnp wieder deaktiviert und Firewallregeln entfernt.


    Nur die Portweiterleitung für Port 5060, von den vom Provider genannten Sip Servern zur Fritzbox, habe ich belassen. Weiterhin die State Timeouts auf 600 Sekunden.

    Einmal editiert, zuletzt von razor () aus folgendem Grund: Ein Beitrag von Renek83 mit diesem Beitrag zusammengefügt.

    Gefällt mir 1

    Vielen Dank für deine Lösung. Ich hatte den Hinweis nicht gesehen und mir dann ein Fritz.Fon gekauft.

    Das funktioniert aber sehr lange tadellos.

    😂😂


    Und am Ende fand es meine Frau auch noch besser so