Fehlerhaftes RTP-Routing bei mehreren ARF-Netzen mit All-IP

[Jirka]

Hallo zusammen,

da mit der All-IP-Option eine Anmeldung von SIP-Clients über WAN nicht mehr möglich ist, schlittert man immer wieder in das bereits schon vor einigen Jahren von mir gemeldete Problem, dass die Telefonie von SIP-Clients über VPN in Verbindung mit der Verwendung von mehreren ARF-Netzen nicht möglich ist, da ein fehlerhaftes Routing bzw. eine fehlerhafte Angabe der RTP-Daten erfolgt. Workarounds sind zwar möglich, wie von mir hier im Forum auch bereits geschrieben (http://www.lancom-forum.de/lancom-syste ... tml#p79388), aber auf Dauer nervig. Ich nehme an, dass der Bug in Vergessenheit geraten ist und möchte diesen mit diesem Posting noch mal in Erinnerung rufen, weil so schwierig kann ich es mir auch nicht vorstellen, das Problem mal zu fixen.

Ausgangslage:
Router mit mehreren (aktiven) ARF-Netzen, z. B.
Netz-1 mit 10.10.13.1/255.255.255.0, Typ Intranet, VLAN 0, Schnittstellen-Tag 13
Netz-2 mit 10.10.133.1/255.255.255.0, Typ Intranet, VLAN 133, Schnittstellen-Tag 133

Entscheidend ist, wie die Netze sortiert sind. Netz-1 ist aufgrund der oben angegebenen Parameter vor Netz-2 einsortiert.

Nun besteht eine VPN-Verbindung zwischen Netz-2 und einem Netz der Gegenseite. Die VPN-Verbindung funktioniert soweit und wird bereits genutzt. Nun soll ein SIP-Client über diese VPN-Verbindung am LANCOM registriert werden, was soweit auch ohne Probleme funktioniert. Anrufe können initiiert und auch signalisiert werden, das Problem ist nur, es ist nichts zu hören.

Schaut man sich den SIP-Packet-Trace an, der seines Namens mittlerweile leider eigentlich nicht mehr gerecht wird, so stellt man fest, dass der LANCOM dem SIP-Client im Session Description Protocol mitteilt, dass er die RTP-Daten doch bitte an die IP-Adresse des ersten (aktiven) ARF-Netzes des LANCOMs schicken soll, also in diesem Beispiel an die 10.10.13.1, statt an die IP-Adresse des ARF-Netzes, an dem sich der Client auch registriert hat. Das funktioniert natürlich leider nicht, weil es zu dem Netz gar keine VPN-Verbindung gibt und geben soll und weil das Netz auf der anderen Seite ganz woanders hinführt. Im Router selber werden die RTP-Daten mit Ziel SIP-Client zwar zum richtigen Ziel abgeschickt (es gibt da auch eine extra Route zum SIP-Client mit Routing-Tag 0), aber mit der falschen Absende-IP-Adresse. In der Folge steht im VPN-Packet-Trace "no policy found for: 10.10.13.1->10.10.10.11 200 UDP port 9696->5062" und das Paket wird verworfen.

Vielen Dank und viele Grüße,
Jirka

[backslash]

Hi Jirka,

ich hab's mal als Bug eingetragen....

Gruß
Backslash

[awi]

Hi Jirka,

hast Du die dazu passende Konfiguration und vielleicht auch einen Trace? (Sip-Packet und Callmanager)
Dann kann ich mir das mal anschauen.

Gruß
awi

[Jirka]

Hallo,

ab 9.10.0526 soll dieses Problem gefixt sein.

Vielen Dank und viele Grüße,
Jirka

[Koppelfeld]

dass er die RTP-Daten doch bitte an die IP-Adresse des ersten (aktiven) ARF-Netzes des LANCOMs schicken soll, also in diesem Beispiel an die 10.10.13.1, statt an die IP-Adresse des ARF-Netzes, an dem sich der Client auch registriert hat.

Dumme Frage: Hast Du bei der korrespondierenden "SIP-Leitung" auch das passende Tag gesetzt ?

[Jirka]

Die korrespondierende SIP-Leitung spielt hier eigentlich nicht so die Rolle. Von und zu selbiger funktioniert im Fehlerfall auch alles. Sie geht zum VoIP-Provider normal über WAN mit Routing-Tag 0. Die Pakete bleiben auf dem Weg zum Client stecken, bzw. (die andere Richtung) der Client schickt sie an eine falsche Adresse (weil diese ihm so mitgeteilt wurde). Für einen SIP-Client kann man aber kein Routing-Tag angeben (Was manchmal eine Einschränkung ist, wenn es in eine VPN-Strecke nur mit einem gewissen Routing-Tag geht um zu verhindern, dass andere ARF-Netze auch Zugriff auf das VPN-Netz haben. Hier muss man als Workaround eine Route zum entsprechenden SIP-Client mit Routing-Tag 0 erstellen, wie oben auch geschrieben.).
Was Du oft machst, ist ISDN auf die SIP-Leitungen auszugeben und dann muss man natürlich auf das entsprechende Routing-Tag achten und dann klappt das auch alles. Aber ich kann die SIP-Leitungen (vom LANCOM) nicht am SIP-Client registrieren lassen (in Deinem Fall jedoch an einem SIP-Server).

[Koppelfeld]

Die korrespondierende SIP-Leitung spielt hier eigentlich nicht so die Rolle. Von und zu selbiger funktioniert im Fehlerfall auch alles.

Mein Fehler, linguistische Konfusion:
"SIP-Leitung" im LANCOM-Sprech: VCM-SIP-Client
"SIP-User": VCM-SIP-Account
Und bei letzterem kannst Du gar kein Tag angeben.

[Jirka]

Eigentlich könnte so ein SIP-Client, wenn er sich denn am LANCOM anmeldet, automatisch das passende Routing-Tag zugewiesen bekommen, denn es steht ja fest, von welcher (VPN-)Gegenstelle er kommt und dass es dort hin wieder zurück muss. Die Angabe ist also eigentlich überflüssig und müsste eigentlich, wenn man sie denn einführt, als einschränkender Filter genutzt werden, womit man festlegen/einschränken kann, von welchen ARF-Netzen/VPN-Gegenstellen eine Anmeldung zulässig ist. Aber das wäre dann auch ein neues Feature. Also ich schaue erst mal, wie sich die neue Firmware verhält.

Viele Grüße,
Jirka

[Jirka]

Hallo,

so, gerade getestet und alles funktioniert, wie es soll. (Getestet mit 9.10.0528.)

Vielen Dank und viele Grüße,
Jirka