Die Beta ist auf der anderen Anlage, wo nicht mal INVITES ankommen 
Werde das aber morgen auf der hier auch noch testen, obgleich ich da wenig Hoffnung habe.
Wir hatten vor den Umstellungen mit Problemen beim doch recht „neuen“ SIP-Trunk gerechnet, aber die funktionieren alle aus dem Stand, mit ansonsten identischer Konfig. Dass die Standardanschlüsse hier Ärger machen, überrascht mich…
mfg, Archetim
Hallo Archetim,
wenn ich dich richtig verstehe, hast Du jetzt zwei Situationen. Den Trunk, wo wir im Moment glauben, dass das Telekomrouting noch nicht korrekt ist - und die Standardanschlüsse, wo INVITES ankommen, die aber von der Anlage ignoriert werden.
Zu letzterem hatte ich in der Vergangenheit auch Fälle. Die hingen alle mit fragmentierten Paketen zusammen. Das tritt auf, wenn Pakete größer als 1500byte werden. Hier solltest Du in Deinem Wiresharkmitschnitt schauen, ob der fehlerhafte Fall so einer ist. Da in Deinem PDF nur die Textdarstellung ist, kann ich nicht abschätzen, wie groß das originale Paket war. Auffällig ist jedoch, dass es größer ist, als der funktionierende Fall. Dies ist ua. durch viele Codecs (haufenweise Mobilfunkcodecs…) begründet.
Lange Rede - kurzer Sinn. Du sagst, Du würdest zwei mal NAT machen. NAT bei UDP-Paketen ist etwas kitzliger, als bei TCP. Die Standardanschlüsse der Telekom laufen aber alle über UDP. Die SIP-Trunks über TCP. Von daher der Unterschied.
Was in den Fällen, die mir unterkamen, immer passiert war war, dass der NAT-Router (bei Dir einer der beiden, oder vielleicht sogar beide) die UDP-Prüfsumme nicht korrekt berechnen, wenn sie auf den fragmentierten UDP-Paketen NAT machen. Sie müssen ja für das NAT die Zieladresse von ihrer öffentlichen IP auf die interne IP der Anlage umschreiben. Anschließend müssen sie im UDP-Paket die Prüfsumme anpassen, damit das UDP-Paket wieder gültig wird. Da scheitern Router mitunter, wenn Pakete fragmentiert wurden.
Fragmentiert heißt ja, dass ursprünglich mal ein großes UDP-Paket mit mehr als 1500byte in mehrere kleine zerhackt wurde. Ein NAT-Router muss also, wenn er die Prüfsumme neu baut, erstmal alle Fragmente einsammeln, in allen Paketen die Zieladresse patchen und dann die Prüfsumme über alle Pakete wieder neu berechnen, damit das anschließend resultierende große Paket - wenn es wieder zusammengesetzt wird - wieder ein gültiges UDP-Paket wird. Daran scheitern die NAT-Router gelegentlich.
Konsequenz ist dann, dass am Zielsystem (hier die TK-Anlage) ein kaputtes Paket ankommt, was direkt verworfen wird (sogar werden muss!).
Das Symptom dessen beobachtest Du dann wahrscheinlich.
Der Wireshark kann die UDP-Prüfsummen testen. Das ist aber normalerweise ausgeschaltet. Wenn Du nicht selbst findest, wie man das aktiviert, melde Dich einfach nochmal.
Gruß Dauerbesetzt
Hallo Dauerbesetzt,
danke für den ausführlichen Beitrag, so fit bin ich am Morgen selten 
Ich habe die Problemkreise wohl nicht ganz klar dargestellt.
Ich habe zwei Standorte mit IP Voice/Data Anschluss, beide mit identischer Konfiguration. An beiden kommen keine Anrufe aus Mobilnetzen an, bei einem kommen INVITE und werden ignoriert, beim zweiten kommt gar nichts. Die Logs sind von dem, wo zumindest INVITE durchkommen.
Deine Erklärungen bzgl. Paketfragmentierung ist schlüssig, ich habe ja das Doppel-NAT auch schon im Verdacht. Mal schauen, ob ich es heute hinbekomme, dass am Standort jemand die 4000 mal direkt an den ersten Router umsteckt. Dann hätte ich eine an sich ja übliche Konstellation mit Fritzbox + 4000. Wenn es dann immer noch nicht geht, dann weiss ich wenigstens, dass nicht meine Netztopologie schuld ist.
Ansonsten warte ich auch immer noch auf Rückmeldung von der T. Man schickt alle 4 Stunden Statusmeldungen, dass man noch dran arbeitet. Also scheint auf deren Seite definitiv auch ein Problem zu sein…
mfg, Archetim
Ein klares Jain … wenn ich mich recht erinnere, war in mindestens einem meiner Fälle auch eine Fritze im Spiel. Aktuelle machen das - glaube ich - richtig. Es gab aber wohl Firmwarestände in der Fritze, die da Probleme hatten.
Wenn es dann also immer noch nicht geht, zeigt auch wieder erst ein Wiresharktrace, was los ist - und nicht die Vermutung “in dieser Standardkonstellation wird’s schon gehen” 
Moin.
Ja - wirklich schon sehr gute Hinweise am frühen Morgen. Parallel würde ich dann auch noch die aktuelle Beta-Version verwenden…
@Herrybert Die ist jetzt auch auf der zweiten Anlage drauf, keine Wirkung…
@Dauerbesetzt Anbei mal eine kurze WS-Ansicht, die INVITEs werden tatsächlich fragmentiert.
INVITE aus anderen Netzen sind kürzer und kommen unfragmentiert durch.
mfg, Archetim
Genau dieses Fehlerbild kommt mir bekannt vor.
Wenn Du jetzt im Wireshark so ein INVITE-Paket nimmst, und in der Klartextansicht die UDP-Ebene aufklappst steht dort wahrscheinlich bei Checksum „unverified“.
Wenn Du auf dieses Feld rechtsklickst, gibt’s im Menü der englischen Variante den Punkt „Protocol Preferences“. Wird im Deutschen nicht groß anders heißen. Dort drin gibt es dann den Punkt „Validate the UDP checksum if possible“. Wenn Du das anhakst und die dann berechnete Checksumme anschließend als incorrect angezeigt wird, hat mindestens einer Deiner Router eine latente NAT-Schwäche 
PS: Hier noch ein Bild, was ich mit UDP-Ebene im Wireshark meine:
WS verifiziert nicht, trotz Haken…
Bei funktionierenden Paketen macht er es…
Hatte grad einen Anruf der Portierungsleute bei der Telekom. Man hat mitgeteilt, dass bei diesem Standort, wo die INVITE kommen, telekomseitig alles korrekt sei. Das hatte ich schon vermutet mittlerweile. Sonst würden die INVITE ja nicht kommen.
Ich werde mich mal ins Auto setzen und vorort umstecken, um das Doppel-NAT erstmal auszuschließen. Wenn man den WS-Trace anschaut, sieht man ja, dass das SOPHOS wohl die Packets zerhaut.
mfg, Archetim
Der IP-Layer ist in Deinem Fall rot markiert. Normalerweise heißt das, dass Wireshark dort was komisch findet. Es kann natürlich auch dieser Layer kaputt gegangen sein.
Vor Ort hast Du natürlich mehr Möglichkeiten auch verschiedene Fälle zu probieren. Viel Erfolg!
So… also ohne Doppel-NAT funzt es. Ich sollte wohl mal dringend mit SOPHOS reden, was die da machen 
Der andere Standort geht jetzt auch, selbes Problem. Dort waren die Pakete so kaputt, dass sie von der Anlage nicht mal mehr als INVITE erkennbar waren. Doppel-NAT beseitigt, läuft jetzt.
Vielen Dank in die Runde, besonders an @Dauerbesetzt
Mfg, Archetim
Moin.
Prüfe evtl. parallel auch folgende Punkte (im VoiP-Anbieter der Anlage):
Mache ich, wenn ich das nächste Mal vor Ort bin dort…
Ich habe ja auch das SIP über UDP im Verdacht, das ist ja an sich der einzige richtige Unterschied zwischen SIP-Trunk und IP Voice auf dem Netzwerklayer.
mfg, Archetim
