Auerswald 5020 / sipgate hinter D-Link Router kein Ton nach innen

[stadolf]

Moin allerseits,

ich bin Programmierer, kein TKler; daher sorry, falls folgend Frage etwas zu simpel gestellt wird, ist so ziemlich alles, was ich weiß. Ach, und die Suche ist toll, spuckt aber für mich zu hohe Ergebnisse aus

Ich habe die Router-Ports geöffnet (Port Forwards UDP 5060, 5063, 49151 - 49408 ), sonst aber Firewall-Einstellungen unangetastet gelassen. STUN ist deaktiviert.

Die SIP-Vermittlung funktioniert: wir können Anrufe nach außen tätigen und empfangen (Telefone [innen,analog] und Handys[außen] klingeln). Telefonieren wir von INNEN nach AUßEN, ist alles in bester Ordnung. Ruft ein Telefon von AUßen eines innen an, klingelt das richtige, ABER: Sprachdaten werden nur vom Telefon INNEN nach außen übertragen; was ich ins Handy spreche, kommt innen nicht an!

Hat jemand von Euch eine Idee ? Fehlt noch irgendein Port? Das hier sieht schon etwas nach einer Antwort aus, hilft mir aber nicht wirklich weiter...

Vielen Dank für Eure tatkräftige Unterstützung :blonk:!

 

[gandalf94305]

Unter Administration -> Monitoring -> Portübersicht findest Du die relevanten SIP-Ports. Diese (Achtung: manche sind TCP, andere sind UDP) müssen weitergeleitet werden. STUN sollte aufgrund des symmetrischen NAT im D-Link-Router deaktiviert sein.

Für RTP hätte ich bei D-Link-Routern einen Trigger eingerichtet. Traffic auf 5060-5063/udp oder 5060-5063/tcp sollte den Bereich 49152 - 49408/udp (siehe Portübersicht) weiterleiten. Damit wäre der Datenstrom korrekt durchgeleitet.

Ansonsten hätte ich noch die Echo-Kompensation abgeschaltet, da dies zu Problemen führen kann. Den Outbound-Proxy benötige ich für sipgate bei mir auch nicht...

Wenn das nichts hilft, sollten wir mal ein Wireshark-Protokoll vom Traffic am WAN-Interface des Routers und am LAN-Interface des Routers machen, um zu sehen was hier rein und raus geht.

--gandalf.

 

[stadolf]

Moin und vielen Dank für Deine Antwort, Mod Gandalf!

Habe ein wenig rumprobiert und glaube, Deine Empfehlungen befolgt zu haben, aber ich blicke diesen seltsamen DLink nicht wirklich (Cisco wär mir lieber ). Also, ich hab mal ne Screenshot-Sammlung und ein Wireshark-Protokoll seitens der Anlage erstellt. Es wär supernett, wenn Du da rasch einen Blick drauf werfen könntest.

Das Protokoll hab ich entschärft. Die SIPgate-Teilnehmernummer lautet jetzt 1234567t0.sipconnect.sipgate.de, die "Festnetznummer" 4930987654321 und das Handy: 01234567890. Unsere IP-Adresse ist mit xxen maskiert.

 

[gandalf94305]

Äh... laut Deiner Portübersicht ist sipgate nicht 5063, sondern 5069 ;-) Ansonsten sieht das korrekt aus.

Den Trace muss ich mir noch genauer anschauen... etwas später.

--gandalf.

 

[voip²]

Ich habe die Router-Ports geöffnet (Port Forwards UDP 5060, 5063, 49151 - 49408 ), sonst aber Firewall-Einstellungen unangetastet gelassen. STUN ist deaktiviert.

Das Öffenen der Ports für SIP und/oder RTP sollte eigentlich nicht notwendig sein. Die TK-Anlage kann per NAT-keep-alive dafür sorgen, dass die SIP-Ports von außen erreichbar sind. Bei RTP ist der Port dann erreichbar, wenn die TK-Anlage selbst ihr erstes Paket verschickt hat.

Wie gandalf94305 schon geschrieben hat, ist STUN bei symmetrischem NAT wenig hilfreich bzw. sogar kontra-produktiv. Ich habe mir deinen Trace angesehen und den Verdacht, dass die TK-Anlage STUN für die RTP-Ports durchgeführt hat:

m=audio 61032 RTP/AVP 8 0 101

Der Port 61032 liegt ja nicht im von Auerswald angegebenen Bereich für RTP-Ports, d.h. es dürfte der geNATtete sein. Den kann die Anlage nur per STUN rausgefunden haben.

Generell wäre es bei symmetrischem NAT das beste, wenn das NAT für die Telefonie generell deaktiviert wird. Sollte das nicht möglich sein, kann man nur hoffen, dass SIPgate symmetrisches RTP unterstützt. Bisher konnten sie das, wie es bei dem sipconnect aussieht, weiß ich nicht.

 

[gandalf94305]

Daher stellt sich nun die Frage, wie denn der Provider und der Account in der Anlage konfiguriert sind.

--gandalf.

 

[stadolf]

Here we go again, liebe Freunde Problem besteht noch immer.

Also: @voip2: Du hattest Recht, ich Dummerli hatte in der Konfiguration des Anbieters das Kreuzchen bei STUN stehen gelassen. Ist jetzt weg. Ich versuche seit heut morgen zu verstehen, was Du meinst und allmählich gehn mir Lichter auf.

Ich habe heute mittag mit dem SIPGATE-Support telefoniert (über unsere Anlage, das geht ja wie gesagt ) und wir sind uns beide schon ziemlich einig, dass die Anlage grundsätzlich richtig konfiguriert ist. Problem dürfte viel eher der Router sein (ein großartiges Modell: D-LINK DIR-301, die 1 ist der Haken, dazu später ). Support and Me identifizierten die Port-Weiterleitungen als nicht hilfreich. Er sagte mir, ich solle auf die Virtuellen Server umsteigen, was ich jetzt auch tat. Bitte beachtet bei den virtuellen Servern das Mapping: Sipgate (IN) = 5060 auf Auerswald 5069, vgl. auch die Portübersicht und Konfig. der TK-Anlage. Kein Erfolg.

{ UPDATE : vergessen: der Supporter simulierte mit unserer Konfig unsere Anlage; ich konnte ihn anrufen und alles war paletti. Deswegen gehen wir beide davon aus, dass die TK-Anlage/Konfig. nicht das Problem darstellt... }

Habe anschließend bei den Anwendungsregeln für bestimmte Port-Trigger die RTP-Ports der Auerswald freigemacht (s. Anhang). Kein Erfolg.

Zwischenzeitlich habe ich wieder ein wenig mit den Portfreigaben herumgespielt. Kein Erfolg.

Letzte Konsequenz: Firmware-Update des Routers ?! Sipgate empfiehlt das in manchem PDF, das ich gefunden habe. Dummerweise bietet D-LINK für den DIR-301 nur Updates an, die für uns nicht zu passen scheinen (Blick ins README); daher "trau" ich mich grad nicht, ein Update zu machen und den Router zu bricken -> das ginge dann nämlich auf meine Rechnung

Habe erneut ein Protokoll (diesmal binär und wieder geXXXt) als ZIP angehängt...

 

[voip²]

Das klingt alles mysteriös.

Um etwas Licht ins dunkle zu bringen, könntest du noch folgendes tun:

1. Starte in der Weboberfläche der TK-Anlage den Netzwerktrace. (Das ist irgendwo unten bei Administration)
2. Nachdem (!) der Trace gestartet ist, führst du eines der nicht funktionierenden Gespräche und legst wieder auf.
3. Dann stoppst du den Trace.

Den Trace kannst du mit Wireshark öffnen. Hier prüfst du folgendes: Gibt es neben dem ausgehenden RTP-Strom auch einen eingehenden? Eventuell wird er nicht als RTP gekennzeichnet, sollte aber trotzdem leicht zu identifizieren sein.

- Wenn es keinen solchen Strom, wird er vom Router geblockt.

- Wenn es einen solchen Strom gibt, von welchem Port kommt er? Passt dieser Port zu dem Port, den SIPgate im INVITE angegeben hat? (SDP-Part, die Zeile, die ich weiter oben schon mal genannt hatte). Stimmt das nicht überein, so wird die Anlage die Pakete wohl wegwerfen. Das gleiche gilt für die IP-Adresse des Stroms und der im SDP-Part.

Dazu kann es z.b. kommen, wenn der Router in den SIP-Nachrichten IP-Adressen und Ports patched... Solche "Features" kommen in Routern immer mehr in Mode, funktionieren aber nur selten.

Solltest du Schwierigkeiten mit der Analyse haben, kann ich da gerne mal reinsehen.

 

[gandalf94305]

Die Firmware könnte das Problem in der Tat sein. In diesem Thread fand ich einen Hinweis auf ebenso einen SIP-ALG wie in meinem Netgear-Router. Wie ich bereits feststellen konnte, funktionieren SIP ALGs, die dann den eingehenden RTP-Strom als von sich (und nicht vom Provider) kommen lassen, nicht mit der Auerswald-Anlage. Prüfe mal die Firmware-Versionen.

--gandalf.

 

[stadolf]

ARGH. Ich hatte nicht verstanden, dass das Log, das die Auerswald erzeugt, bereits binärkompatibel von Wireshark gelesen werden kann. Habe einen "Durchgang" auf diese Weise gecaptured und als ZIP angehängt.

@Gandalf: die Router-FW ist mir in der Tat suspekt. Du hattest offensichtlich einige Suchworte bei Google eingegeben; Dein Treffer ist imho aber irrelevant (Dein Link betrifft DLink-Router 60x mit Firmware-Version 301-310, unser Router ist DIR-301 mit FirmwareVersion 1.02b blabla ). Ich glaub, das hier ist aber das falsche Forum, um über Router- und Firmware-Probleme zu diskutieren oder ?

OK, ich hab mal das Protokoll gescreent und dabei folgendes festgestellt (wenig verwunderlich):

Zwei aufeinanderfolgende RTP-Protokoll-Snips aus Szenario innen ruft an, alles schicki:

User Datagram Protocol, Src Port: 46474 (46474), Dst Port: 49232 (49232) 
Real-Time Transport Protocol

User Datagram Protocol, Src Port: 49232 (49232), Dst Port: 46474 (46474)
Real-Time Transport Protocol

-> d.h. die Kommunikation funktioniert, Auerswald (Port 49232, lt. FW nach innen frei) kommuniziert mit Sipgate (Port 46474, nach außen ohnehin frei)

Im Szenario Handy ruft an >> wir hören des Anrufers Stimme nicht weist Wireshark nur einen einzigen Package-Typ aus, nämlich Src=Auerswald, Dst=Sipgate:

User Datagram Protocol, Src Port: 49236 (49236), Dst Port: 18738 (18738)

Und das find ich jetzt überraschend, denn WTF hat denn 18738 da verloren und wohin antwortet Sipgate wohl ?? Auf jeden Fall stützt das Protokoll voip²'s These Nr.1.

Die ALG-Geschichte von Gandalf find ich plausibel, aber ich weiß nicht, welche FW ich gefahrlos auf den D-Link spielen darf -> gebt Euch das hier: ftp://ftp.dlink.de/dir/dir-301/driver_software/ <<< das ist die offizielle Quelle. Ich unzips im Geiste mal für Euch und les Euch das README vor:

Diese Firmware/Software darf nur für das angegebene Produkt verwendet werden, achten Sie besonders auf
die Hardware Revision, z.B.: H/W B2, oder Rev. A3!
Die Verwendung in einem anderen/ähnlichem Produkt kann dieses Produkt unbrauchbar machen und führt
zum Erlöschen Ihrer Produkt-Garantie.

Mein Router: Hardware-Version: A1 Firmware-Version: 1.02. In der D-Link-FAQ steht (ich hab den Link verbummelt...) sinngemäß: Wer einen A-Router mit B-Firmware flasht, wird mit Freiheitsstrafe nicht unter 3 Jahren bestraft oder muss eine große Flasche Wurzelpeter exxen. Wenn ich in zwei Stunden verzweifelt genug bin, schreib ich Euch, wies war

 

[gandalf94305]

User Datagram Protocol, Src Port: 49236 (49236), Dst Port: 18738 (18738)

Und das find ich jetzt überraschend, denn WTF hat denn 18738 da verloren und wohin antwortet Sipgate wohl ??

18738 ist der sipgate-seitige Port und das ist ja auch ok so. Die Frage ist nur, als welcher Port kommt 42236 draußen bei sipgate an und wohin anwortet sipgate. Wir sollten nun einen Wireshark-Dump vom WAN-Interface des D-Link-Routers sehen können ;-)

--gandalf.

 

[stadolf]

Genau das ist jetzt der Punkt an dem ich aussteige -> woher krieg ich so ein Protokoll ? Das Logging des Routers ist dafür nicht zu gebrauchen... DMZ ?

 

[gandalf94305]

Der einfachste Fall wäre, einen kleinen Repeater an den WAN-Port zu klemmen und dem Traffic zwischen Router und Internet zuzuhören.

Schau auch bei D-Link mal ins Forum und stelle die Frage nach SIP ALGs.

--gandalf.