SIP RTP Routing bei Vernetzungen

[Dr.Einstein]

Hallo zusammen,

mit zunehmender All IP Option und damit verbunden mit mehr SIP Providern statt ISDN Anschlüssen kommt es des Öfteren zu Problemen, die früher so nicht aufgetreten sind. Vielleicht hat der ein oder andere eine Idee, wie man dies umgehen bzw. beheben kann.

Ausgangslage sind zwei Lancom Router, die eine VPN Vernetzung aufbauen um eine Telefonievernetzung zu ermöglichen. Das heißt, entweder stehen an je einem Standort eine TK-Anlage, die vernetzt sind, oder eine TK-Anlage an einem Standort und IP-Telefone an dem anderen Standort. "Früher" hatten die TK-Anlagen immer ISDN Basis- oder PMX Anschlüsse, weshalb beim IP-Routing der Abschlusspunkt immer die TK-Anlage war aus Sicht der RTP Pakete.

Jetzt kommt aber das Problem hinzu: Der ISDN Anschluss wird umgewandelt in einen SIP Anschluss. Wenn jetzt ein Telefongespräch über den SIP Provider reinkommt, und für den 2. Standort durchgestellt wird, kommt es zur einseitiger Verständigung. Ursache ist die Quelle IP-Adresse des SIP-Proxys/Providers, der in allen RTP Paketen hinterlegt ist. Dabei spielt es keine Rolle, ob die TK-Anlage selbst die SIP Daten konfiguriert hat oder der Lancom Router. Man könnte jetzt z.B. im Lancom Router für das Szenario TK-Anlage <-> IP-Telefone mittels Policy Based Routing jeglichen IP-Traffic der Telefone über den Tunnel routen, funktioniert, Problem gelöst. Wenn jetzt aber zwei TK-Anlage vernetzt sind, war es das schon wieder mit dem Workaround. Oder aber es handelt sich nicht um ein IP-Telefon, sondern um ein SIP-Client auf einem PC, würde ja jeglicher Traffic des PCs über den Tunnel gehen, auch nicht unbedingt sinnvoll.

Ich suche nach Lösungsvorschlägen, Ideen etc. wie man gegen dieses Problem vorgehen könnte. Vielleicht übersehe ich ja was grundsätzliches. Bis jetzt hatte ich nur eine TK-Anlage, wo man die SIP Terminierung explizit erzwingen konnte, sprich Abschlusspunkt jeglicher RTP Ströme ist die TK-Anlage.

Gruß Dr.Einstein

[Koppelfeld]

Wenn jetzt ein Telefongespräch über den SIP Provider reinkommt, und für den 2. Standort durchgestellt wird, kommt es zur einseitiger Verständigung.

Initial 'bridget' eine TK-Anlage oder ein Gateway zunächst einmal den empfangenen Channel und den des Weiterleitungsziels. Nach Zustandekommen des Gesprächs setzt die Anlage aber typischerweise einen 'SIP REINVITE' ab, mit der Bitte, die 'call legs' mögen sich doch direkt untereinander verbinden.

Unter Asterisk haben wir die beobachteten Probleme häufig; ein beherztes 'canreinvite = no' in der SIP-Konfiguration für das Gateway sorgt für Ruhe. Bzw. genau für das (beabsichtigte) Gegenteil.

[Dr.Einstein]

Hallo Koppelfeld,

danke für deine Antwort. Die Asterisk war genau die Anlage, wo so eine Möglichkeit da ist. Eventuell hat das "Feature" fast jede Anlage nur die Namensbezeichnung dafür ist so merkwürdig, dass man einfach nicht drauf kommt.

Beim Lancom mit VoIP Option habe ich diesen Punkt z.B. auch nicht gefunden.

Gruß Dr.Einstein

[cpuprofi]

Hallo Dr.Einstein,

...Wenn jetzt ein Telefongespräch über den SIP Provider reinkommt, und für den 2. Standort durchgestellt wird, kommt es zur einseitiger Verständigung. Ursache ist die Quelle IP-Adresse des SIP-Proxys/Providers, der in allen RTP Paketen hinterlegt ist...

normalerweise sollte der SIP-ALG dieses "Problem" lösen, da er ja alle IP's in den Paketen umschreibt (Eingehend und Ausgehend. Zumindest in meinen Test's Anfang des Jahres).

Wie weit das aber bei Dir funktioniert....?

Grüße aus dem Urlaub
Cpuprofi

[Jirka]

Hallo Dr. Einstein,

Wenn jetzt ein Telefongespräch über den SIP Provider reinkommt, und für den 2. Standort durchgestellt wird, kommt es zu einseitiger Verständigung. Ursache ist die Quelle IP-Adresse des SIP-Proxys/Providers, der in allen RTP Paketen hinterlegt ist.

also dies ist aber sehr unsauber ausgedrückt, denn in den RTP-Paketen findet sich dafür definitiv nichts.

Dabei spielt es keine Rolle, ob die TK-Anlage selbst die SIP Daten konfiguriert hat oder der Lancom Router.

Na doch, ein Unterschied ist da schon... Nur führt ein seit Jahren existierender Bug im LANCOM leider dazu, dass unter gewissen Konstellationen, die Sprachdaten leider nicht an das richtige ARF-Netz raus gehen...

Eventuell hat das "Feature" fast jede Anlage, nur die Namensbezeichnung dafür ist so merkwürdig, dass man einfach nicht drauf kommt.

Ja, da sollte man von ausgehen.

Beim Lancom mit VoIP Option habe ich diesen Punkt z.B. auch nicht gefunden.

Da gibt es ihn auch nicht. Seit der Einführung des Media-Proxys (2008) gehen die RTP-Pakete grundsätzlich über den LANCOM. Auch innerhalb eines lokalen Netzes ist das so.
Wenn dies über VPN-Tunnel oder/und mit mehreren ARF-Netzen nicht funktioniert, dann kann das einerseits daran liegen, dass SIP-Benutzern im LANCOM kein Routing-Tag zugewiesen werden kann und daher immer eine Route zu der IP des SIP-Benutzers mit Routing-Tag 0 in der Routing-Tabelle vorhanden sein muss (einfach zusätzlich eintragen, damit die Route mit Tag für die sonstigen VPN-Zugriffe bzw. zur automatischen Erstellung der Netzbeziehungen erhalten bleibt), oder aber, und das ist halt der Bug, dass lokal immer nur an das erste (aktive [oft ist noch das ungenutzte DMZ-Netz davor]) ARF-Netz in der Liste der IP-Netzwerke zugestellt werden kann, wo man dann als Workaround die Reihenfolge mit Hilfe der Schnittstellen-Tags bzw. auch mit der Wahl der IP-Adressen derart ändern kann, dass es eben das erste ist...

Viele Grüße,
Jirka

[Dr.Einstein]

Hallo Jirka,

also dies ist aber sehr unsauber ausgedrückt, denn in den RTP-Paketen findet sich dafür definitiv nichts.

Ja, ich geb dir Recht. Im SIP, bzw. im SDP Bereich steht die öffentliche IP Adresse des Providers zur Annahme der RTP Ströme. RTP selbst macht es dann einfach gehirnlos, was ja korrekt ist.

Na doch, ein Unterschied ist da schon... Nur führt ein seit Jahren existierender Bug im LANCOM leider dazu, dass unter gewissen Konstellationen, die Sprachdaten leider nicht an das richtige ARF-Netz raus gehen...

Scheinbar bin ich bei meinen Tests voreilig auf einen weiteren / alten Fehler gestoßen. Hatte mich erst ein paar Stunden mit verschiedenen Anlagen und Konstellationen auseinandergesetzt und am Ende mal den Lancom getestet. Da hierbei ähnliche Probleme auftraten, hab ich es einfach in die gleiche Schublade gepackt und mir die Trace gespart. Habe es jetzt nochmal nachgestellt. Wie du korrekterweise sagst, kein Reinvite, Lancom ersetzt SDP/RTP Adresse des Providers durch sich selbst. Durch Schnittstellen-Tags / Routing Tags scheinen da die Probleme entstanden zu sein, keine Zeit momentan, da weiter nachzuforschen. Test mit zwei nackigen Lancoms + VPN + All IP -> SIP war auf jeden Fall erfolgreich.

Hallo cpuprofi,

normalerweise sollte der SIP-ALG dieses "Problem" lösen, da er ja alle IP's in den Paketen umschreibt (Eingehend und Ausgehend. Zumindest in meinen Test's Anfang des Jahres).

War das jetzt ernst gemeint, oder wolltest du mich nur ärgern? Mit ALG funktioniert ja nicht einmal lokal mit meiner Testanlage ein Gespräch.

Auf jeden Fall werde ich erst einmal den Support der TK-Anlagen einschalten, wo man diese ReInvites unterdrücken kann. Ansonsten kann man ja scheinbar die All IP Option des Lancoms dazu verwenden, den SDP Inhalt abzuändern. Ist nur an sich wieder eine Fehlerquelle mehr (dafür aber ein guter ALG).

Danke soweit an euch.

Gruß Dr.Einstein

[marsbewohner]

normalerweise sollte der SIP-ALG dieses "Problem" lösen, da er ja alle IP's in den Paketen umschreibt (Eingehend und Ausgehend. Zumindest in meinen Test's Anfang des Jahres).

War das jetzt ernst gemeint, oder wolltest du mich nur ärgern? Mit ALG funktioniert ja nicht einmal lokal mit meiner Testanlage ein Gespräch.

Hallo Dr. Einstein,

da habe ich zumindest mit den Beta Version der 9.10er Serie gute Erfahrungen gemacht, das sich das gebessert hat. In meinem Szenario zwar immer mit extern gehosteten PBXs, dort aber zuverlässig und gefundene + gemeldete Bugs hat der Support während der Beta Phase auch alle gut wegbekommen

Gruß,

[cpuprofi]

Hallo Dr.Einstein,

...Mit ALG funktioniert ja nicht einmal lokal mit meiner Testanlage ein Gespräch...

eigentlich war das ernst gemeint...

Ich habe gerade mal getestet:

PhonerLite (als SIP-Client, Anmeldung per WAN an 1722) <-> VPN <-> 1781VA (mit SIP-ALG) <-> 1722 (als TK-Anlage, intern hinter den 1781VA)

Was soll ich sagen... es geht!

Grüße
Cpuprofi