Wenn es über das falsche Interface gesendet würde, müßte es aber auch an der Gegenstelle auftauchen.
Aber auch nur dann, wenn dieses Interface mit der Gegenstelle verbunden ist - ansonsten kriegt das sogar im WAN-Stack (je nach Konfiguration der FRITZ!Box und der Interfaces) noch eine andere Absenderadresse und wird deshalb schon von der "Gegenstelle" abgelehnt bzw. es landet auf dem LAN- anstelle des WAN-Interfaces (oder umgekehrt, denn so ergiebig ist die Beschreibung in #1 nun auch wieder nicht, daß man erkennen könnte, ob die beiden Boxen über WAN oder LAN miteinander kommunizieren müßten).
In den Support-Daten finde ich auch nur INVITE bei einem Call und sonst nichts (kein Trying, Ringing).
Dann suchst Du an der falschen Stelle ... es gibt aber tatsächlich noch einen zweiten Ringbuffer, in dem nur die INVITE-Messages (halt doppelt, dafür aber auch länger, weil keine anderen Pakete sie so schnell verdrängen, wie es bei den kompletten Dialogen der Fall ist) geführt werden. In dem, den ich meine, stehen aber alle SIP-Messages, die der "voipd" verarbeitet und zwar sowohl die eingehenden als auch die selbst gesendeten.
Daß es sich um einen Fehler des FRITZ!OS handelt (selbst wenn das Paket auf dem falschen Interface gesendet wird), habe ich ja nie bestritten. Wenn Du Deinerseits schon eingangs feststellst, daß Dein Ticket bei AVM gerade von jemandem bearbeitet wird, der von SIP-Dialogen (und dann unterstelle ich mal, auch von deren "Speicherung" - aka "Protokollierung") im FRITZ!OS wenig Ahnung hat, dann interpretiere ich das halt (sofern da nichts anderes steht, z.B. "Erfahrungsbericht") als Aufforderung, Dir Hinweise zu geben, wie man sich selbst dem Fehler "nähern" könnte und wie man - wenn's gut läuft - auch seinen Workaround finden könnte, falls es bei AVM länger dauert.
Wenn das gar nicht Deine Absicht sein sollte, vergiss das Ganze einfach wieder ... es ändert aber auch nichts daran, daß der Wireshark-Mitschnitt eben nur zeigt, daß das ACK-Paket im Dialog nicht auf
diesem Interface zu sehen ist.
Wenn man sich die Arbeitsweise des "voipd" ein wenig genauer ansieht (dazu gehört auch das Protokollieren des Interfaces in dem erwähnten Ringbuffer, auf dem die Message gesendet oder empfangen wurde) und sich mit den Möglichkeiten der Konfiguration der "hints" in der "voipd.cfg" näher befaßt, kriegt man vermutlich auch eine Idee, worauf ich meinerseits hier hinauswill.
Es macht eben einen Unterschied (wenn auch nicht im Hinblick auf das Ergebnis, das ist in beiden Fällen dasselbe, nämlich "geht nicht"), ob das Paket gar nicht erzeugt und gesendet wird oder ob es "nur" auf dem falschen Interface landet. Beides ist zweifellos ein Fehler, aber letzterem könnte man eben versuchen entgegenzuwirken, indem man anstelle des Standardwertes "automatisch" für die Auswahl des Interfaces (für die Registrierung der Nummer - damit wird (bzw. wurde zumindest früher) aber auch das bevorzugte Interface zur Kommunikation im Zusammenhang mit diesem Account festgelegt) eine "genauere" Angabe macht.
Bringt aber ohnehin alles nur dann etwas, wenn man dem Problem selbst näher zuleibe rücken will (diese Absicht unterstellte ich hier, da Du von Wireshark-Mitschnitten berichtet hast) und der Feststellung, daß das Paket nicht da ankommt, wo es ankommen müßte, noch eine genauere Ursache (wird es gar nicht gesendet oder an die falsche Adresse/in die falsche Richtung) hinzufügen wollte.
