Sooo… ich glaub wir haben einen einen kleinen Durchbruch mit Blues Unicast Problem
In seinen Traces konnte man sehen, dass im Fehlerfall im SETUP Request ein anderer Client-Port genannt war, als in der Antwort des Servers. Und damit kommt der 401er wohl nicht klar, jedenfalls schickt er dann nicht die benötigten NAT-Pakete los, damit der Server ihm Daten schicken kann und fordert das PLAY auch nicht an.
Spannend ist dann aber der Blick auf den Trace im WAN, denn dort sind die Ports die gleichen. Oder anders ausgedrückt, der Router schreibt den SETUP Request offenbar um. Das macht er aber nur dann, wenn der genannte Port bereits bei ihm belegt ist und das ist der Fall, wenn der andere Receiver zufällig den gleichen Port benutzt. Und das ist gar nicht sooo unwahrscheinlich, da die Receiver scheinbar nach dem Einschalten immer mit Port 3160 beginnen und dann hochzählen. Wenn man beide Receiver also gleichzeitig einschaltet und einigermaßen gleichhäufig auf Unicast-Kanäle schaltet, sind die immer im gleichen Port-Bereich unterwegs. Und das ist auch der Grund, warum wir das bisher wahrscheinlich noch nicht hatten, weil zumindest ich immer den Zweitreceiver nur zum Test eingeschaltet hatte und der Hauptreceiver schon länger lief. Ausserdem ist das höchstwahrscheinlich auch ein fritzbox Thema, das muss ich bei Gelegenheit aber noch mal mit einem Speedport gegentesten.
Vielleicht noch ein Beispiel zur Verdeutlichung:
LAN, Receiver 1 frisch nach dem Einschalten, Wechsel auf Unicast
SETUP rtsp://87.141.220.115:554/url RTSP/1.0
...
Transport: MP2T/RTP/UDP;unicast;client_port=3160
RTSP/1.0 200 OK
...
Transport: MP2T/RTP/UDP;unicast;client_port=3160;source=87.141.220.115;server_port=32154-32155;ssrc=2604190
x-NAT:on
Wie man sieht sagt der Client client_port 3160 und vom Server bekommt er den gleichen Port wieder genannt.
LAN, Receiver 2 frisch gestartet, schaltet auf einen Unicast Kanal
SETUP rtsp://87.141.220.115:554/url
...
Transport: MP2T/RTP/UDP;unicast;client_port=3160
RTSP/1.0 200 OK
...
Transport: MP2T/RTP/UDP;unicast;client_port=61002;source=87.141.220.115;server_port=32214-32215;ssrc=2604203
So, wie man sieht will der 2. Receiver auch den Port 3160 nutzen, vom Server kommt dann aber client_port=61002 zurück.
Zuerst dachte ich: ist der Server dumm oder was, warum ändert der den Client Port, damit hat er doch nichts zu tun. Des Rätsels Lösung findet sich aber, wenn man sich die gleichen Pakete nicht im LAN, sondern WAN anschaut:
SETUP rtsp://87.141.220.115:554/url RTSP/1.0
...
Transport: MP2T/RTP/UDP;unicast;client_port=61002
RTSP/1.0 200 OK
...
Transport: MP2T/RTP/UDP;unicast;client_port=61002;source=87.141.220.115;server_port=32214-32215;ssrc=2604203
Hier sieht man nämlich, dass das Paket, das zum Server geht, plötzlich den Port 61002 nennt. Sprich die Fritzbox hat den client_port einfach geändert, macht das aber nicht bei der Antwort des Servers. Denn eigentlich müsste beim Server das Paket wieder mit client_port=3160 ankommen.
So und damit kommen wir zum Fazit:
Die Fritzbox erkennt, dass der Port bereits belegt ist und ändert ihn ab, allerdings nur beim Request, nicht bei der Antwort. Daher kann man dem MR eigentlich keinen Vorwurf machen. Der wird vermutlich eine Verbindung mit dem Port suchen, aber nicht finden und den Stream deshalb nicht mehr finden.
Nichtsdestotrotz sind natürlich mehrere Dinge denkbar, denn damit kommen wir zum Thema, warum der 400er das nicht hatte. Leider hab ich auch gerade keinen 400er da, das muss ich noch nachholen, es ergeben sich aber mehrere Varianten damit umzugehen:
- evtl beginnen die 400/200er nicht mit dem gleichen Startport sondern wählen diesen zufällig, das senkt das Risiko erheblich, löst das Problem aber auch nicht zu 100%
- evtl ist den 400/200ern der Client-Port, den ihnen der Server nennt schlicht egal. Wenn ich eigene TCP Verbindungen pro Kanal mache, kann ich auch anhand des Sockets über den die Antwort reinkommt, die Antwort der Anfrage zuordnen.
Und das wären dann wohl auch die beiden “Workarounds”, die beim 401er denkbar wären. Das eigentliche Problem ist imho aber die Fritzbox, die in der einen Richtung ein NAT macht, in der anderen aber nicht.