manchmal keine ankommenden Anrufe (fritzbox als TK-Anlage)

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

    Ob die DNS Server noch die korrekten sind kann ich schwer sagen. Im Netz finde ich für O2 jedenfalls immer die beiden genannten...jedenfalls wird auf diese noch aktuell verwiesen.


    Anbei mal ein paar Screenshots von den Einstellungen:

    UniFi:

    AVM:


    Es ging damals als ich das "Ersteinrichtungsproblem" durch das eintragen der DNS Server gelöst hatte. Ab wann ich nicht mehr angerufen werden kann, lässt sich schwer sagen (Telefon wird hier nicht oft genutzt da alles meist über Mobil abläuft, und raus telefonieren ging ja immer). Wenn ich aber ins Telefon Log der Fritze schaue sehe ich seit ewigkeiten (mehrere Monate) keine ankommenden Anrufe mehr. Daher schwer zu sagen was eine Veränderung gewesen sein könnte.


    Leitung wurde nicht umgestellt - aber Talk aus Neugierde installiert war natürlich ein Treffer :grinning_face_with_smiling_eyes: . Hab es deinstalliert, aber keine Besserung.


    Ich mach mich mal an den dump...

    ok, hier nun der dump:



    Beim Trace bin ich nicht sicher wie ich das am besten auswerte - weiß aber auch nicht ob es eine gute idee ist das hier alles reinzustellen?


    Wenn ich nach VoIP filtere bekomme ich die 6 Invite Ereignisse:


    Wenn ich einem der UDP Streams folge die folgende Ausgabe:

    Genügt das an Auswertung oder kann ich noch mehr Info rausziehen?

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

    Ahh sieht doch schon ganz gut aus...


    Dein Carrier schickt dir INVITES zu dir, versucht sich also zu erreichen. Und es gibt im ersten trace

    zumindestens irgendwas das auch wieder zum carrier zurück geht. Das ist grob schon 50% :smiling_face:

    Die frage ist wer oder was der anfrage antwortet...


    Hätte ich gleich so schreiben sollen


    tcpdump -i any -s 0 -w /root/trace.pcap port 5060


    Das zeichneten traffic für alle Schnittstellen für port 5060 auf.

    Da solltest du dann auch traffic von und zu deiner Fritzbox sehen.

    und die antworten...


    Hattest du die UDM nach entfernen von TALK gebootet ?

    mit netstat -tulpen | grep 5060 kannst du sichergehen das nicht auf der UDM

    auf der 5060 lauscht (Ausgabe sollte leer bleiben).


    bzw (bin nicht 100%ob die ganze Zeit zu sehen ist)

    cat /proc/net/nf_conntrack | grep 5060

    SOLLTE eine Zeile auftauchen wo die Fritzbox ip und die carrier ip erkennst (62.x.x.x in deinem fall)



    BTW, ich finde Port Weiterleitungen nötig. Können aber helfen wenn man eh nur eine Anlage hat.

    Aber deine RTP weitlerleiting von port 5004-5020 is grober Unfug.

    Im zweiten trace m=audio 10472 RTP/AVP 96 9 97 8 98 99 möchte der Carrier über PORT 10472

    mit dir sabbeln.

    Also hier kommt das dabei heraus:



    Die UDM hatte ich neu gestartet, ja.


    netstat -tulpen | grep 5060

    Code
    # netstat -tulpen | grep 5060
netstat: showing only processes with your user ID

    cat /proc/net/nf_conntrack | grep 5060


    Code
    # cat /proc/net/nf_conntrack | grep 5060
ipv4     2 udp      17 273 src=192.168.1.2 dst=62.52.28.195 sport=5060 dport=5060 packets=2742 bytes=212540 src=62.52.28.195 dst=77.181.93.22 sport=5060 dport=5                                                         060 packets=127 bytes=90669 [ASSURED] mark=0 use=2
#


    Zitat von gierig

    BTW, ich finde Port Weiterleitungen nötig. Können aber helfen wenn man eh nur eine Anlage hat.

    Aber deine RTP weitlerleiting von port 5004-5020 is grober Unfug.

    Im zweiten trace m=audio 10472 RTP/AVP 96 9 97 8 98 99 möchte der Carrier über PORT 10472

    mit dir sabbeln.

    Du meintest unnötig? Hatte ich damals beim DNS Problem hinzugefügt, man hangelt sich ja immer durch verschiedene Lösungsvorschläge. MAche ich aber gerne wieder raus :-).


    Benutzte das erste mal Wireshark bzw. Analysiere zum ersten mal sowas. Falls ich noch mehr Info's rausholen kann, bräuchte ich Hilfe :smiling_face:


    Aber danke dir schonmal für deine Hilfe!

    Kick an


    UDM sieht alles gut, ja die RTP regel ist unsinnig weil kommt so eh nicht zum tragen. Die SIP regel ist

    eigentlich auch unnötig, schadet aber nicht solange du ein SIP gerät im netzt hast das nach extern will

    über den 5060 port...


    Der trace schaut aber gut aus:

    Calls zur FritzBox, irgendwas will auch aus der Fritz Box wieder zurück zu Ip der Anruf herkommt

    Das sieht aber nach Grütze aus. Da sollte sowas wie ring/try/ack auftauchen und nicht

    leer bleiben. Ggf ins Paket reinschauen (wird unten angekauft sonst doppelklick)

    nach Ethernet, IP, UDP frame sollte SIP auftauchen mit infos drinnen.


    Aktuell nach Aktenlage macht deine Fritzbox doofe dinge und antworten nicht richtig.

    Auf die schnelle wie es aussehen sollte / kann

    Ob bei dir nun ein Training//200/Ringing/183 steht mag variieren je nach SIP Geschmack.

    Aber irgendwas in der Art muss zurück gehen...



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

    Ne, sieht nach Grütze aus



    Kommt man irgendiwe mit der Fritze weiter?

    Oder erstmal zurücksetzen und neu einrichten?

    Alternativ habe ich ein Gigaset DX800 dran hängen, könnte im ersten Schritt mal versuchen es direkt im Gigaset zu konfigurieren und die Fritze von ihrer Telefonfunktion zu erlösen....ist zwar noch ein ISDN Gerät mit Fax dran in Betrieb, aber das wäre kein großer Verlust.

    Keine Ahnung von Fritz Boxen, meine letze wurde noch mit Dampf betrieben und durfte ähnlich wie deine

    noch als TK Anlage einige Zeit mitspielen. Das müsste ne 7170 von 2005-2006 gewesen sein...schwarz mit

    1und1 logo aber noch ohne software Branding... ach das waren noch unschuldige Zeiten :smiling_face:


    aber

    - Neustart

    - SIP kram löschen / neu Anlegen

    - Werkseinstellungen

    - FW neu draufbüglen


    gilt ja grob für alles :smiling_face:


    Für deine Sicherheit und zum Doppelten check, gleicher trace und dann mal

    Raustelefonieren. Im trace solltest du dann die „SIP“ Pakete sehen diesmal halt

    der invite von deiner box in Netz und die passenden antworten zurück.

    2 Mal editiert, zuletzt von gierig ()

    Neustart hatte ich schon gemacht.


    Doppelcheck trace raustelefonieren sieht von den Antworten her gut aus.


    Interessant ist, das als ich grade in der Fritze schauen wollte, mir auffiel das er nur noch bei einer Rufnummer eine erfolgreiche regisstrierung hat (habe mehrere, nutze aber hauptsächlich nur eine, über die die ganzen Versuche liefen, diese ist auch noch registriert).


    Da ich erstmal wenig Lust habe an der Fritzbox alles neu einzurichten (außer telefonie läuft da aktuell noch das WLAN drüber - ja, das wird auch bald durch Unifi ersetzt), wollte ich zunächst probieren eine der anderen Nummern in der DX800 zu registrieren und zu schauen ob es da geht.


    Die Port Weiterleitung habe ich natürlich vorher deaktiviert.


    Und siehe da - es geht auch da nicht. Raustelefonieren geht, ankommente anrufe nicht. Analyse des trace sieht gleich aus wie bei der FritzBox.


    Nur Zufall das die FritzBox und das Gigaset die gleichen doofe Dinge machen? Oder liegt es doch an der UDM? Oder an O2?


    Zugegeben, die Konfiguration beim Gigaset war nicht einfach - Hier soll ich auch die RTP Ports angeben. Was für einen Port Bereich soll man denn da angeben? Standardmäßig war 5004-5020 eingestellt....

    Denke aber das wahrscheinlich nicht viel fehlerhaft eingestellt sein kann wenn ausgehende Anrufe gehen?

    Zitat von Nubbler

    Hier soll ich auch die RTP Ports angeben.

    Versuch es mal damit:

    • Sprachkanäle: RTP 9000 bis 10999 UTP
    • SIP: 5060 UTP/TCP
    • Tunnel: 5090 UTP/TCP (falls erforderlich)
    • Web: 5001 TCP (falls erforderlich)
    • Stunserver: 3478 UDP (bei dynamischer öffentlicher IP)

    Mhhh mal durch den nichtvorhandnen Bart raufen und über das bisherige sinnieren.

    Zitat von Nubbler

    Nur Zufall das die FritzBox und das Gigaset die gleichen doofe Dinge machen?

    Nein wohl eher nicht. Ich habe zwar schon Dinge gesehen, die ihr Menschen niemals glauben würdet.

    Gigantische Schiffe, die brannten, draußen vor der Schulter des Orion. Und ich habe C-Beams gesehen,

    glitzernd im Dunkeln, nahe dem Tannhäuser Tor. Aber zwei Geräte unterschiedlicher Hersteller die spontan

    den gleichen Grütz machen ? Nein...


    - hast du irgendwie aktive Komponente (switch, bridge, etc) zwischen UDM und deiner Fritz/Gigaset ?

    - Du hast Neustarts durchgeführt, aber hast du auch mal den Stecker gezogen ?
    - Irgendwelche Firewall regeln auf die UDM eingetragen (je nach IDS trägt das ding da auch selber regeln ein)


    Wobei letzteres eher der letze Strohhalm ist. Die Pakete gehen ja raus. Firewall würden sie vernichten auf den weg raus.

    Aber nicht „leeren“ und weiterleiten ( und tcpdunp sollte Pakete for eher Firewall Capture) aber mit diesen

    ganzen hardwareOffloadSwitch halb ins OS Integriert weis Man ja nicht...


    Im Grunde würde ich man in the mittel machen und zwischen UDM und Fritz noch einen switch hängen auf

    dem ich den traffic Spiegeln kann auf einen dritten port und dann von da mitzuschneiden..


    Von Gefühl ist es nun doch eher die UDM die das was macht...auch wenn sie das so nicht sollte...

    Firewall und Stecker ziehen...


    schon seltsam...

    Oje, jetzt werden meine ganzen nicht vorhandenen Skills gefragt.


    Also die Fritze hängt direkt am UDM Pro, am UDM pro hängt noch ein 24er switch an dem das Gigaset hängt.


    Also hab ich das der einfachheit halber mit dem Gigaset probiert:


    Gigaset Port an den Port an dem der Laptop hängt gespiegelt und mit Wireshark abgehört (an dieser stelle bin ich nicht sicher ob ich das alles richtig mache :smiling_face: Learning by doing.


    Nach 5060 gefiltert.

    Ausgehende Anrufe sehe ich ganz normal (Invite; ACK usw.)

    EIngehende Anrufe tauchen gar nicht auf (Also den Invite den man im Trace von der UDM noch gesehen hat, kommt schon nicht an).


    Also als Laie interpretiert gibt die UDM den nicht ans interne Netz weiter?


    Firewallregeln hab ich glaube ich noch nix dran gedreht, sollte Standard sein?


    Internet:

    3001 Accept All Internet In allow established/related sessions

    3002 Drop All Internet In drop invalid state

    3001 Accept All Internet Local allow established/related sessions

    3002 Drop All Internet Local drop invalid state


    LAN

    6001 Accept All LAN In accounting defined network 192.168.1.0/24

    6001 Accept All LAN Out accounting defined network 192.168.1.0/24


    Threat Management ausschalten brachte ja auch nichts.


    Achja, und Stecker raus, ja, hatte ich gemacht.


    Gibt es eventuell eine Art von Firewallregel bei der ich das durchlassen von VoIP nochmal erlaube? DA hab ich mich noch nicht ran getraut...

    Einmal editiert, zuletzt von Nubbler ()

    Also eins muss man bei SIP mit FRITZ!Box auf keinen Fall

    Irgendwelche eingehenden Firewall regeln erlauben !


    Stört zwar der FRITZ!Box nicht, aber jede Regel die öffnet ist eine Tür


    Wie funktioniert SIP

    Die FRITZ!Box baut eine Verbindung zu deinem SIP Provider auf, meist ist dieser dein Internet Provider und hier ist der Punkt 1 warum das ab und zu nicht funktioniert.

    Der Provider möchte seine eigenen DNS Server haben. Also gehört der DNS Server deines providers auch fest vorgegeben in die FRITZ!Box

    Wenn die FRITZ!Box den Port zum SIP Server geöffnet hat, dann hält er ihn offen um eingehende Verbindungen zu erlauben, hier passiert Fehler Möglichkeit Punkt 2

    In der FRITZ!Box muss eingeschaltet sein, den Port aktiv offen zu halten und dies auch alle 5 Minuten zu erneuern (der Punkt stand hier oben im Forum schon mal mit printscreen)

    Was passiert wenn der SIP Server nun über den von der FRITZ!Box offen gehaltenen Kanal einen Anruf meldet (oder umgekehrt du rufst an). Es wird ein zufällig gewählter neuer Port zum SIP Server geöffnet (von der FRITZ!Box aus), es ist also völlig unnötig (und unmöglich) den Port eingehend frei geben zu müssen, weil Dein Netzwerk immer die Verbindung aushandelt.

    Das einzige in einer Firewall was sein muss, das die FRITZ!Box Zugang zum Internet haben darf und selber Ports öffnen darf und das auf diesen geantwortet werden darf. Also allow established related -> das ist deshalb auch eine Standard Regel für alle deine Geräte, weil sonst könnte das Internet nicht antworten 😉


    Mehr ist in der Magie eigentlich nicht drin


    PS: falls du VLAN nutzt sollte so eine Regel auch in LAN sein, sonst antworten angesprochene Geräte nicht,

    Einmal editiert, zuletzt von uboot21 ()

    Gefällt mir 1
    Zitat von uboot21

    Wie funktioniert SIP

    Die FRITZ!Box baut eine Verbindung zu deinem SIP Provider auf, meist ist dieser dein Internet Provider und hier ist der Punkt 1 warum das ab und zu nicht funktioniert.

    Der Provider möchte seine eigenen DNS Server haben. Also gehört der DNS Server deines providers auch fest vorgegeben in die FRITZ!Box

    Nun ja, dass ist wohl eine etwas sehr vereinfachte Darstellung, tatsächlich ist der Ablauf eines VoIP-Telefonat etwas komplexer:

    1. alle VoIP-SIP-Teilnehmer müssen eine SIP-Adresse im URI-Format, wie zum Beispiel „sip:[email protected]“, besitzen. Hierbei stellt „88888“ den Benutzernamen und „beispiel.com“ die Domain darstellt.
    2. die SIP-Endgeräte (User Agents) müssen sich mit dieser SIP-Adresse, ihrer IP-Adresse und Port, unter welchen sie per SIP erreichbar sind, beim SIP-Registrar-Server ihrer Domain (hier z.B. "beispiel.com") registrieren.
    3. Soll nun ein Telefonat initiert werden, sendet der User Agent des Anrufers eine Nachricht mit der anzurufenden SIP-Adresse (im URI-Format) an den Server des eigenen SIP-Providers (SIP-Proxy).
    4. Dieser Anrufwunsch wird dann durch den SIP-Proxy der eigenen Domain an den SIP-Proxy der anzurufenden Domain weitergeleitet. Dieser ermittelt mit Hilfe des SIP-Location-Service IP-Nummer und Port der angerufenen SIP-Adresse und leitet die Anrufwunsch-Nachricht an den User Agent des Angerufenen weiter.
    5. Wenn die Anfrage beim Angerufenen verarbeitet werden kann (daher dieser erreichbar ist), schickt dessen User Agent eine entsprechende Nachricht über die beteiligten Server zurück zum Anrufer.
    6. Erst jetzt klingelt das Endgerät des Angerufenen und der Anrufer hört das Freitzeichen.
    7. Während des Verbindungsaufbaus unter 5. und 6. werden zwischen beteiligten User Agents alle notwendigen Informationen über die Eigenschaften und Fähigkeiten der Agents und des zu führenen Telefonats ausgetauscht (z.B. einigen diese sich über den anzuwendenden Audio-Codec, die Ports zur Gesprächsführung, eventuelle Verschlüsselungsfragen, etc.). Eine direkte Kommunikation zwischen den beiden User Agents selbst hat bis hierhin noch nicht stattgefunden, bisher lief alles über die Proxy-Server und über das SIP-Protokoll und i.d.R. über TCP.
    8. Für das eigentliche Telefongespräch sind dann die Proxy-Server nicht mehr notwendig. Nach Annahme des Gesprächs durch den Angerufenen, werden beide beteiligte User Agents direkt miteinader verbunden - das Telefonat läuft komplett an den Proxy-Servern vorbei. Hierbei verwenden dann die User Agents i.d.R. das Real-Time Transport Protocol (RTP) über UTP.
    9. Erst zum Beendigung des Gesprächs kommen dann wieder die Proxy-Server ins Spiel. Hier sendet einer der User Agents eine SIP-Nachricht an seinen SIP-Proxy-Server, welche diese an den anderen Teilnehmer weitergibt und beide Endgeräte beenden dann Verbindung.

    Soweit die etwas vereinfachte Darstellung des Verlauf eines VoIP-Telefonats mittels des Session Initiation Protocol (SIP). Wie der Name des Protokolls schon sagt, kümmert sich SIP lediglich um den Verbindungsaufbau (und Beendigung) und nicht um das Gespräch selbst (daher kann man damit auch z.B. Videoübertragungen initieren).


    DNS -um auf uboot21 einzugehen- kommt in diesem Zusammenhang zweimal ins Spiel, einmal unter Punkt 2., da man als Teilnehmer von seinem SIP-Provider i.d.R. nur die URLs der Server mitgeteilt bekommt und zum zweiten Mal unter Punkten 3./4., hier muss nämlich der eigene SIP-Proxy-Server des Anzurufenden ermittel. Welchen DNS-Server man nun selbst verwendet um die URLs der SIP-Server des eigenen Providers aufzulösen, ist eigentlich egal und bei mir funktioniert dies genauso über Quad9, Claudflare, Google, etc., wie alle anderen Anfragen auch.


    An sonst sieht man jedoch am oben geschilderten Ablauf, das beim Aufbau eines VoIP-Telefonates schon einiges schief gehen kann. Am einfachsten funktioniert es immer dann, wenn man als User Agents direkt an der Netzwerkkante sitzende Kisten verwendet, wie z.B. eine Fritzbox oder eine BeIP. Diese kümmern sich bei der Einrichtung von VoIP selbst um die eigenen Firewallregeln und kennen auch die eigene öffentlich IP.


    Hat man jedoch seinen User Agent im LAN, muss man sich selbst um die Firewall und die Übermittlung der eigenen öffentlichen IP bemühen und hier wird es dann gelegentlich knifflig. Für ausgehende Gespräche funktioniert dies oft recht einfach (so lange der User Agent beim Registrar-Server auch registriert ist), denn hier kommt aller Traffic aus dem LAN und die Firewall sperrt sich nicht so zickig. Für eingehende Telefonate sieht das dann anders aus, hier muss man dann schon selbst dafür sorgen, dass die passenden Ports offen sind - welche dafür in Betracht kommen, schrieb ich ja schon oben. Gelegentlich ist dann auch noch die Ermittlung der eigenen öffentlichen IP erforderlich (diese kann einem User Agent im LAN per se ja nicht bekannt sein), hierfür nutzt man dann eine Stun-Server, welche diese Adresse von außen abfragt und dem User Agent mitteilt.


    Also @TE - kümmere Dich um Deine Firewall :smiling_face:


    Nubbler

    Firewall sieht gut, jedenfalls wenn die einzigen sind. Wenn du auf der UDM den IVITE siehts sollte su ih auch auf

    deinem Mirror Port sehen. Wenn nicht wird er verschluckt oder geht woanders hin. (Fritze noch aktiv) ?

    (sofern keine festen Weiterleitungen sollte "cat /proc/net/nf_conntrack | grep 5060“ auf welches ziel das Paket geht.

    Steht hier nichts is die Tabelle schon wider gelöscht oder dein Telefon hat sich nicht rechtzeitig wieder refrescht.

    Zur not halt die UDP Timeouts auf 15 min setzen, da ist LAAAANGE aber für ein test ganz angenehm)


    Nun wird aber recht schwer „remote“ noch Tips zu geben.


    bic

    .....im Prinzip eine schöne Ausführung. Aber an der Realität ein wenig vorbei.

    Kein Wort zu Registrierung Refresh, Session Refresh. der Tatsache das eben NICHT RTP direkt aufgebaut wird

    sondern im Endkunden Business IMMER über den Proxy/SBC (genau über Media Gateway) gegangen wird.


    Und nein JEDER Endkunden Carrier weis das seine Kunden zu 99%Hinter einem (p)NAT router sitzen.

    Die SBCs können alle mit NAT umgehen und ignorieren Daten im FROM, Contact, PAI, SDP Media headdern

    und senden es einfach an die IP die sich registriert hat. (im übrigen einer der Gründe warum keine direkte Verbindung

    ermöglicht wird, Kunde für mit falschen IP kommen).


    Damit eingehen funktioniert sind genau zwei dinge nötig:

    • Die Registrierung des UAC am Proxy
    • Das regelmäßige Senden von Informationen von UAC zu de Proxy damit das (p) nat die Verbindung nicht nach x Minuten vergisst.


    Das passiert Überlichweise im Endkunden Geschäft über Neuregestrieren / Refresh der Anmeldung.

    Fritzbox und andere können darüberhinaus (Verbindung offen halten) einfach SIP Pakete schicken

    (Option Request ist das mittel der Wahl). Manchmal ist es nötig an der Timing der NAT Tabelle rumzudrehen

    was hier schon das Thema war...


    DER TO kann Raustelefonieren, sieht die INVITES ankommen auf der UDM und die Fritz!Box antwortet scheinbar mit leeren Pakete ist das aktuelle Thema. Da ist irgendwo was faul. Die frage ist bloß wo genau...

    Zitat von bic

    Also @TE - kümmere Dich um Deine Firewall

    Um das nochmal deutlich zu sagen, nein hier ist alles gut soweit zu sehen ist.

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

    Zitat von gierig

    .....im Prinzip eine schöne Ausführung. Aber an der Realität ein wenig vorbei.

    Aha ... dann steht dem aber doch nichst im Weg, wenn Du das passend ergänzt und erläuterst, aber so, das es ein Dummy auch versteht. Wenn du das dann erledigt hast, schauen wir mal, ob es stimmt :smiling_face:


    An sonst - wie die SIP-Aushandlung im einzelnen erfolgt, dazu schrieb ich ja überhaupt nicht, stattdessen jedoch "Soweit die etwas vereinfachte Darstellung des Verlauf eines VoIP-Telefonats". Wer es genauer wissen will, kann ja z.B. hier nachlesen (und wird das von mir Geschriebene bestätigt finden).


    Außerdem, was hat das Ignorieren von Options-Anforderungen durch den SIP-Anbieter mit dem grundsätzlichen Zustandekommen einer SIP-Verbindung zu tun? Auch dessen Wissen darüber, ob ein User Agent hinter einem (Port)NAT-Router sitzt oder nicht, hilft diesem kein Stück weiter, darum muss der Agent sich schon selbst kümmern. Am Prinzip ändert das jedoch alles nichts: Verbindungsaufbau per SIP, die Sprachübertragung dann über RTP.


    Zitat von gierig

    DER TO, kann Raustelefonieren, sieht die INVITES ankommen auf der UDM und die Fritz box antwortet scheinbar

    mit leeren Pakete ist das aktuelle Thema. Da ist irgendwo was faul. die frage ist bloß wo genau...

    Genau - und das Gigaset DX800 hat sich mit verschworen :winking_face:

    Zitat von gierig

    Um das nochmal deutlich zu sagen, nein hier ist alles gut soweit zu sehen ist.

    Glaub ich Dir ohne Weiteres, wenn Du denn dann im Detail weißt, was die durchnummerierten Regeln der UDM tatsächlich bewirken. Außerdem schrieb der TE:

    Zitat von Nubbler

    Nach 5060 gefiltert.

    Ausgehende Anrufe sehe ich ganz normal (Invite; ACK usw.)

    EIngehende Anrufe tauchen gar nicht auf (Also den Invite den man im Trace von der UDM noch gesehen hat, kommt schon nicht an).

    Es bleibt also dabei:

    Zitat von bic

    Also @TE - kümmere Dich um Deine Firewall

    Also zunächst kam

    Code
    ipv4     2 udp      17 286 src=192.168.1.5 dst=62.52.28.195 sport=5060 dport=5060 packets=4113 bytes=178301 src=62.52.28.195 dst=77.181.86.52 sport=5060 dport=1024 packets=125 bytes=125800 [ASSURED] mark=0 use=2
ipv4     2 udp      17 295 src=192.168.1.2 dst=62.52.28.195 sport=5060 dport=5060 packets=2751 bytes=115907 src=62.52.28.195 dst=77.181.86.52 sport=5060 dport=5060 packets=27 bytes=17399 [ASSURED] mark=0 use=2

    Also erste Zeile ist src das Gigaset, die zweite die Fritzbox

    Nachdem ich dann einmal raustelefoniert und danach erfolglos reintelefoniert habe kamen neue Einträge dazu:

    Code
    ipv4     2 tcp      6 109 TIME_WAIT src=127.0.0.1 dst=127.0.0.1 sport=50604 dport=8080 packets=6 bytes=10266 src=127.0.0.1 dst=127.0.0.1 sport=8080 dport=50604 packets=4 bytes=469 [ASSURED] mark=0 use=2
ipv4     2 tcp      6 105 TIME_WAIT src=127.0.0.1 dst=127.0.0.1 sport=50600 dport=1080 packets=9 bytes=701 src=127.0.0.1 dst=127.0.0.1 sport=1080 dport=50600 packets=9 bytes=15110 [ASSURED] mark=0 use=2
ipv4     2 udp      17 106 src=127.0.0.1 dst=127.0.0.1 sport=35060 dport=53 packets=1 bytes=55 src=127.0.0.1 dst=127.0.0.1 sport=53 dport=35060 packets=1 bytes=55 mark=0 use=2
ipv4     2 udp      17 296 src=192.168.1.5 dst=62.52.28.195 sport=5060 dport=5060 packets=4205 bytes=181740 src=62.52.28.195 dst=77.181.86.52 sport=5060 dport=1024 packets=133 bytes=139109 [ASSURED] mark=0 use=2
ipv4     2 udp      17 274 src=192.168.1.2 dst=62.52.28.195 sport=5060 dport=5060 packets=2813 bytes=119754 src=62.52.28.195 dst=77.181.86.52 sport=5060 dport=5060 packets=37 bytes=33678 [ASSURED] mark=0 use=2

    Nach einiger Zeit sind dann wieder nur die beiden Einträge der ersten Abfrage vorhanden.


    Um die Firewall kümmern...Nun ja, da bräuchte ich dann schon genaue Handlungsemfehlungen...


    Danke für eure Diskussion aber bitte nicht streiten :-).


    Bin kurz davor einfach mal die UDM komplett zurückzusetzen und einfach mal alles neu aufzubauen......Wenn es so schwierig ist weiter zu kommen.


    Was mich immer noch wundert ist, das die Fritze aktuell nur eine Rufnummer registiert (habe mehrere durch die ISDN Option, wobei aktuell nur noch 2 in Benutzung sind). Aktuell ist hier nur die Hauptnummer auf "grün". EIne der anderen bei der DX800 zu registrieren hat funktioniert.

    update:

    Lt. google reicht anscheinend eine Rufnummer in der Fritze aus, das diese den Port 5060 abgreift.

    Daher konzentriere ich mich nun es rein mit dem DX800 ans laufen zu bekommen. Nicht das die Fritze das irgendwie beeinflußt.


    Also alle Rufnummern aus der Fritze gelöscht und neugestartet.

    Beide Rufnummern in der DX800 registriert.

    UDM Pro neu gestartet.


    Nun bringt cat /proc/net/nf_conntrack | grep 5060


    Code
    ipv4     2 udp      17 610 src=192.168.1.5 dst=62.52.28.195 sport=5060 dport=5060 packets=2 bytes=1048 src=62.52.28.195 dst=77.189.76.161 sport=5060 dport=5060 packets=2 bytes=1132 [ASSURED] mark=0 use=2
ipv4     2 udp      17 712 src=192.168.1.234 dst=217.91.44.17 sport=50606 dport=123 packets=1 bytes=76 src=217.91.44.17 dst=77.189.76.161 sport=123 dport=50606 packets=1 bytes=76 mark=0 use=2
ipv4     2 udp      17 1494 src=192.168.1.5 dst=62.53.165.195 sport=5060 dport=5060 packets=59 bytes=13229 src=62.53.165.195 dst=77.189.76.161 sport=5060 dport=5060 packets=39 bytes=51483 [ASSURED] mark=0 use=2

    Also zwei einträge für die DX800.

    Den dritten eintrag kann ich mir aber nicht erklären.

    192.168.1.234 ist ein raspberry mit Kodi.

    217.91.44.17 ist laut nslookup kashra.com

    Laut google ein Laden für Akkus.


    Ich versteh's nicht mehr, bin raus.

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

    Schau auf den Port dein KODI spricht mit port 50606. Grep findet alles wo 5060 drinnen steht. Schau auf den DEST Port das ist 123

    auf der 217.91.44.17


    inetnum: 217.91.0.0 - 217.91.127.255

    netname: DTAG-STATIC01

    descr: Deutsche Telekom AG

    descr: T-DSL Business static dial-up


    pool.ntp.org: Statistics for 217.91.44.17


    Ist ein NTP Server, Dein Kodi oder eher dein Raspi fragt die Uhrzeit ab...

    bic, sorry wenn ich die auf die Füsse getreten bin das war nicht meine Absicht.

    2 Mal editiert, zuletzt von razor () aus folgendem Grund: Ein Beitrag von gierig mit diesem Beitrag zusammengefügt.

    Zitat von Nubbler

    Um die Firewall kümmern...Nun ja, da bräuchte ich dann schon genaue Handlungsemfehlungen...

    Da könnte ich Dir bei allen möglichen Routern sicher helfen, bei der UDM jedoch leider nicht, von der weiß ich nur, dass es diese gibt :grinning_face_with_smiling_eyes:


    An sonst sind ja tatsächlich nur zwei Protokolle betroffen, einmal SIP und RTP. Ist nur eine SIP-User-Agent im LAN vorhanden, ist man gut bedient, bei diesen für das SIP-Protokoll den Port 5060 (TCP/UDP) zu verwenden. Für RTP (UDP) benötigt man mehrere Ports, bzw. mindesten zwei (einer als Sprachkanal und einer für die Statusinformationen), wobei aber hier ein Abstand von 4 Ports empfohlen wird. Für RTP kommt hier alles über 1024 in Frage (und wird beim Verbindungsaufbau ausgehandelt) und die Fritten verwenden hier gem. AVM UDP 7078 bis 7097 (übrigens, hat man mehrere User-Agent im LAN -z.B. Fritzbox und DX800-, empfiehlt es sich, jeden einen eigenen SIP-Port und einen eigenen RTP-Portbereich zuzuordnen)


    Für o.a. Protokolle mit ihren Ports gilt es nun, deren Weg durch die Firewall freizuschaufeln. Bei manchen FW-Routern ist dies ganz einfach, denn diese verfügen über eine Routine namens Application-Layer-Gateway (ALG), diese sorgt von ganz allein dafür, dass VoIP funktioniert - irgendwelche Einstellungen sind hier nicht nötig (z.B. bei meinen Sophos XGs und auch bereist bei meinen 15 Jahre alten Netgear SRX5308). Hat der Router diese Funktion nun nicht, bzw. funktioniert diese nicht, beißt sich mit anderen NAT-Regeln (zur Hauptsache mit Destinations(D)NAT) oder verlangt der User Agent deren Abschaltung (3CX) dann muss man selbst für den freien Weg sorgen.


    Bei SIP ist diese i.d.R. recht einfach, denn die Verbindungsanforderung kommt von innen, die FW öffnet den Port und dieser ist nun auch von außen erreichbar. Dies bleibt dann (mit einer Karenzzeit) solange so, wie Traffic über den Port fließt und damit das auch so bleibt, initiert z.B. die Fritte entsprechenden Dummy-Verkehr und hält so den Port offen. Sollte das aus irgendwelchen Gründen fehlschlagen, rettet eine Portweiterleitung (DNAT) die Situation. AVM schreibt dazu:


    "Richten Sie im Router eine Portweiterleitung von UDP-Port 5060 auf Port 5060 der FRITZ!Box ein"


    Letzteres, also die Portweiterleitung ist dann für RTP von vornherein zwingend erforderlich, denn hierbei handelt es sich um eine Verbindungsanforderung von außen. Um jedoch diese Weiterleitung einrichten zu können, muss jedoch erst einmal der RTP-Portbereich bekannt sein, auf welchen der jeweilige User Agent lauscht. Wie o.a. ist dies bei der Fritzbox der Bereich 7078-7097, welchen Bereich jedoch die DX800 verwendet,. Jedenfalls schreibt AVM dazu:


    "Richten Sie im Router statische Portweiterleitungen von beliebigen UDP-Ports >= 1024 (z.B. 6078-6097) auf die Ports 7078-7097 der FRITZ!Box ein."


    Warum hier nun AVM die Ports umgeschrieben haben will, weiß ich nicht, bei mir funktioniert es mit der 3CX jedenfalls ohne Umschreibung problemlos (kann man ja ausprobieren). An sonst sollte es das dann gewesen sein, ggfflls. sollte man die Quelle des eingehenden Traffic noch auf das Netz des eigenen Providers beschränken, aber auf jeden Fall ein etwaiges ALG abschalten - wie auch immer dies sich bei UI nennt.


    So, nun ist es Deine Aufgabe zu schauen, wie Du dies bei der UDM umgesetzt bekommst :winking_face:

    Hallo zusammen,


    erstmal vielen Dank für euren Input, insbesondere gierig und bic für die Mühe.


    Habe nun viel gelernt über VoIP bzw. erstmals in der Praxis Wireshark benutzt.


    Dennoch wollte ich nun nicht unbedingt das Risiko eingehen und mit der Firewall herumspielen um mir dann noch eventuell mehr Probleme ins Haus zu holen.


    Ich habe die UDM Pro resetet, Conntrack H.323 und SIP auf aus, timings auf 300 und ich kann nun wieder angerufen werden!


    Portweiterleitungen waren nicht notwendig.


    Ausgehende Anrufe gingen zuerst nicht, aber nach einer Weile dann doch - ich hoffe das bleibt stabil.


    Zunächst nur an der DX800. Werde die Tage dann mal eine der Nummern an der Fritze ausprobieren und berichten (den Weg bräuchte ich für das Fax - wäre aber nicht so wild wenn das dann nicht geht).


    Thread Management ist allerdings noch deaktiviert - Versuche ich dann noch morgen ob es einen negativen Einfluß hat (wenn ich das TElefon öfters klingeln lassen kann, ist nun zu spät) - aber vorher hatte das ausschalten ja keine verbesserung gebracht, hoffe das es dann jetzt auch keine verschlechterung bringt.


    grüße

    Nubbler

    Zitat von Nubbler

    Thread Management ist allerdings noch deaktiviert - Versuche ich dann noch morgen ob es einen negativen Einfluß hat (wenn ich das TElefon öfters klingeln lassen kann

    Stand Heute sind keine O2 SIP IP den IDS Rules, sie tauchen auch nicht bei den ca. 1400 Firewall regeln auf die sich hinter „TOR und ALIEN“ Block verbergen.

    Sollte das IDS was blocken siehst du es aber in den LOGS und zusätzliche die dann angelegt werden.


    Anroste Glückwunsch auch wenns seltsam ist..

    Zitat von bic

    Für RTP (UDP) benötigt man mehrere Ports, bzw. mindesten zwei (einer als Sprachkanal und einer für die Statusinformationen), wobei aber hier ein Abstand von 4 Ports empfohlen wird.

    Wer empfiehlt sowas ?


    Üblicherweise wird der Sprachkanal auf einem graden Port aufgebaut und die RTCP auf den nächsten ungeraden.


    Siehe RFC 3550 - Section 11

    For UDP and similar protocols, RTP SHOULD use an even destination port number and the corresponding RTCP stream SHOULD use the next higher (odd) destination port number.


    Klar sollte Seuche und es muß sich keiner dran halten, aber offensichtlich wird ein von irgendjemanden empfohlen.


    Aber um wieder auf ein Fuß zu treten:

    Endkunden Carrier wie Telekom, Telefonica (o2), und die große Vodafon Bubble (UM, Kabel, Alice.),

    sipGate uvm, werden einen Teufel tun und RTCP zu ihren Kunden schicken oder empfangen. Nachher steht da noch ein

    schlechter MOS Score drinn und der Kunde fängt an zu reklamieren...und hat dann noch was in der Hand....

    Nein nein nein... ein PORT für den Sprachkanal reicht. Alles andere wird überschätzt und braucht nur unnötige Ressourcen.


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

    Zitat von gierig

    Üblicherweise wird der Sprachkanal auf einem graden Port aufgebaut und die RTCP auf den nächsten

    ungeraden.

    Da muss ich doch direkt mal bei mir schauen :smiling_face:

    Zitat von gierig

    Klar sollte Seuche

    ?????

    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:



    So wie es ausschaut, verwendet meine 3CX doch zwei RTP-Ports - diese liegen aber tatsächlich direkt nebeneinander :smiling_face: Aber vielleicht interpretiere ich das ja nur falsch.