[1781VAW] SIP-ALG verursacht Verbindungsabbruch

[shrike]

Hallo,
zur Zeit leide ich an Verbindungsabbrüchen nach 15min am All-IP Anschluß der Telekom bei abgehenden Gesprächen. Die SIP-Pakete zeigen, daß eben genau nach dieser Zeit ein RE-INVITE der Gegenstelle ankommt, das meine Auerswald 5020VOIP mit "call does not exist" beantwortet. Konsequenterweise legt dann die Gegenstelle auf. Der SIP-ALG im Lancom war dabei aktiv.

Bei einem Gegentest ohne SIP-ALG (dafür mit port fowarding und firewall Regeln im Lancom) reagiert die Auerswald korrekt auf den RE-INVITE und das Gespräch bricht nicht ab.

Die Ursache ist also der SIP-ALG, der wohl irgend einen SIP-Parameter in dem kommenden RE-INVITE falsch umsetzt. Hat jemand eine vergleichbare Konstellation und ein Lösung für mich?

Der Lancom läuft mit der 9.10.0530 firmware.

Gruß,
Shrike

[5624]

Ich habe mittlerweile aufgegeben, das SIP-ALG zu nutzen. Seitdem funktionieren meine Auerswald-Anlagen problemlos. Es sind noch nicht mal Port-Weiterleitungen nötig. Nur eine QoS-Regel.

Wichtig ist, dass du die Auerswald auf der aktuellsten Firmware betreibst und das entsprechende Providerprofil nutzt, was Online angeboten wird, nicht das auf der Anlage mitgelieferte Profil. (das korrekte heißt glaube ich momentan de Telekom MagentaZuhause IPv4 V901)

Mit dem ALG hatte ich schon die lustigsten Phänomene.

[shrike]

Ja, sieht wohl so aus, dass der SIP-ALG in Zusammenhang mit Auerswald-Anlagen unbrauchbar ist. Schade eigentlich, es wäre eine elegante und saubere Lösung für TK-Anlagen hinter NAT gewesen.

Danke für's feedback.

Gruß,
Shike

[cpuprofi]

Hallo an Alle,

Ja, sieht wohl so aus, dass der SIP-ALG in Zusammenhang mit Auerswald-Anlagen unbrauchbar ist.

das mag so sein, dass der "Lancom SIP-ALG mit Auerswald VoIP" oder auch "Auerswald VoIP mit Lancom SIP-ALG" nicht funktioniert bzw. kann...

Schade eigentlich, es wäre eine elegante und saubere Lösung für TK-Anlagen hinter NAT gewesen.

Das ist leider wieder eine zu oberflächliche Betrachtungsweise. Der Lancom SIP-ALG funktioniert bei mir und div. Kunden super bei (richtigen) SIP-TK-Anlagen, wie Mobydick, Starface, Telpho...

Es hängt bei VoIP ja immer an mehreren Komponenten und deren Zusammenspiel.

Grüße
Cpuprofi

[shrike]

Ich gebe zu, dass meine Verallgemeinerung auf alle TK-Anlagen in meinem zweiten Satz unfair war und nehme dies deshalb zurück.

Mein Vertrauen in den Lancom SIP-ALG schwindet halt etwas:

• wenn ich eine extra DROP Regel brauche, weil frühe RTP Pakete nicht an die TK-Anlage weitergereicht werden
• wenn ich beobachte, dass alle RTCP-Pakete (RTP port +1) nicht an die TK-Anlage weitergereicht werden

Gruß,
Shrike

[cpuprofi]

Hallo Shrike,

...wenn ich eine extra DROP Regel brauche, weil frühe RTP Pakete nicht an die TK-Anlage weitergereicht werden

da gebe ich Dir Recht, aber dieses ist schlicht nicht Programmierbar, wenn VoIP-Provider vorab schon RTP's senden ohne das ein SIP-Paket mit den Port-Daten angekommen ist...

...wenn ich beobachte, dass alle RTCP-Pakete (RTP port +1) nicht an die TK-Anlage weitergereicht werden

Soweit ich das weiß, macht der SIP-ALG das. Problematisch ist RTCP dann, wenn dieses nicht vom Provider (der den SIP-Aufbau gemacht hat), sondern von der Gegenstelle (SIP-Telefon) über den Provider durchgereicht bzw. direkt geschickt wird, dann stimmen meist die Ports nicht mehr. Sipgate würde mir so als Beispiel dazu einfallen.

Ansonsten bin ich mit dem was der SIP-ALG z.Z. kann schon ganz zufrieden. Es gibt viele "Mitbeweber" von Lancom wo der SIP-ALG viel weniger kann bzw. weniger funktioniert.

Wobei ich Dir auch Recht geben muß, dass man immer etwas gutes auch noch verbessern bzw. optimieren kann.

Grüße
Cpuprofi

[Koppelfeld]

Ja, sieht wohl so aus, dass der SIP-ALG in Zusammenhang mit Auerswald-Anlagen unbrauchbar ist. Schade eigentlich, es wäre eine elegante und saubere Lösung für TK-Anlagen hinter NAT gewesen.

Elegant und sauber ist der Voic-Call-Manager - der eliminiert das NAT-Problem, statt es zu kaschieren.
Bitte immer bedenken: NAT I-S-T bereits eine elende Pfuschlösung ! Ein ALG macht die nicht besser.

Kaputtes Telekom-SIP + NAT + Kaputtes Auserswald-SIP + sehr eigenwilliges LANCOM-ALG:
Ich würde sagen, da sind drei Provisorien zu viel in der Kette.

Mit dem VCM investierst Du 50 Euro, die sich lohnen, zumal Du damit den Vorteil hast, mit bestimmten Accounts 'Policy Routing' betreiben zu können.

[shrike]

Hallo Koppelfeld,
irgendwie komm ich mit den Informationen über die Funktionen des Voice-Call-Manager nicht ganz klar. Es scheint ein Teil der All-IP Option für meinen Router zu sein; als eigenständige Option hab ich den VCM nirgends gefunden.

Ausgehend von der All-IP Option, meinst du dann ich soll die Auerswald zur ISDN-Anlage degradieren? ... das wäre dann aber ein Rückschritt (nur 2 gleichzeitige Gespräche). Oder fungiert da der VCM als interner SIP-Provider, an dem ich die Auerswald registrieren kann?

Gruß,
Shrike

[cpuprofi]

Hallo Shrike,

...irgendwie komm ich mit den Informationen über die Funktionen des Voice-Call-Manager nicht ganz klar. Es scheint ein Teil der All-IP Option für meinen Router zu sein; als eigenständige Option hab ich den VCM nirgends gefunden...

was Koppelfeld mit "VCM" ausdrückte ist die "ALL-IP Option". Denn die "ALL-IP Option" entstammte dem alten "Voice-Call-Manager" der 1722-1724er Lancoms.

...Ausgehend von der All-IP Option, meinst du dann ich soll die Auerswald zur ISDN-Anlage degradieren? ... das wäre dann aber ein Rückschritt (nur 2 gleichzeitige Gespräche)...

Warum? Die ALL-IP Option ist doch ein "richtiger" SIP-Proxy.

...Oder fungiert da der VCM als interner SIP-Provider, an dem ich die Auerswald registrieren kann?...

Ja, das geht.

Grüße
Cpuprofi

[shrike]

Ok, das hört sich gut an. Ich werd' mir dann mal diese All-IP Option besorgen.

Vielen Dank und Gruß,
Shrike

[cpuprofi]

Hallo Shrike,

die Anbindung sieht dann so aus:

Telekom VoIP-Server <- SIP -> Lancom mit ALL-IP Option <- SIP -> Auerswald SIP-TK-Anlage

Sollte so alles laufen. Bedenke aber die ALL-IP Option kann nicht auf allen Lancoms installiert/freigeschaltet werden.

Grüße
Cpuprofi

[shrike]

Hallo cpuprofi,
mein 1781VAW ist geeignet für die All-IP Option.

Was mich zuversichtlich stimmt, ist dass die Telekom selber den 1781VAW + All-IP Option als Router für Geschäftskunden anbietet. Auf der WAN-Seite sollte ich somit auf der sicheren Seite sein. Ob der VCM mit den Eigenheiten des Auerswald-SIPs zurechtkommt, werd' ich sehen. Bestellt hab' ich die Option bereits.

Gruß,
Shrike

[marsbewohner]

Hi,

in dem Zusammenhang noch als Tipp, ich habe bisher mit dem Support gute Erfahrungen gemacht, wenn man SIP-ALG Probleme mit Traces belegbar darstellen kann, das hier dann auch entsprechend etwas angepasst wurde. Ich hatte div. Probleme mit Unify und Gigaset Systemen, und die wurden bisher alle zufriedenstellend behoben!

Gruß,

[shrike]

Hallo zusammen und ein frohes neues Jahr,
obwohl ich mich eigentlich schon für den VCM entschieden hab, bin ich nochmal die Protokolle bei aktiviertem SIP-ALG durchgegangen. Und ich denke ich hab die Kernursache ausmachen können. Der nachfolgende trace der Netzwerkpakete ist gleichzeitig auf WAN und LAN gemacht. Das heißt, man sieht die Pakete doppelt; einmal mit WAN- und nochmal mit LAN-Adressierung.

sip_sequence2.png

Es fällt auf, dass der SIP:PRACK request von der Auerswald auf WAN-Seite vom Lancom auf einen anderen Quellport (11982), als der vorangegangene SIP:INVITE (10490) gemappt wird (was ich nicht so richtig verstehe). Das zurückkommende SIP:OK auf diesen request wird aber nicht mehr zur Auerswald weitergegeben. Ob nun der Fehler im Lancom das neuerliche port mapping oder das fehlende zurückmapping ist, weiß ich nicht. Auf alle Fälle ist damit der Beweis erbracht, dass die Auerswald nicht der Verursacher des Problems ist.

Gruß,
Shrike

edit: Telefonnummer geschwärzt

[cpuprofi]

Hallo Shrike,

man müsste jetzt sich ganz genau die einzelnen SIP-Pakete anschauen und versuchen heraus zu bekommen, woher der Port 11982 herrührt. Irgendwie muß es ja begründet sein, warum der SIP-ALG diesen verwendet...?!?

Grüße
Cpuprofi