All-IP/VoIP: SIP-Registrierung dauert viel zu lange

[Dr.Einstein]

Vielleicht könnte ein Admin den Thread aufteilen:

Ab lancom-systems-voip-router-f42/all-ip-v ... tml#p97177 sind es Voiceprobleme mit LCOS 10.20, vor besagtem Beitrag Re-Register-Timer

Sonst findet man die Beiträge in 1..2 Jahren nicht mehr

Gruß Dr.Einstein

[Jirka]

Du meinst echt, dass mein "Re-Register-Timer bei Nichtregistrierung"-Problem in 1..2 Jahren mal angegangen wird? Na ja, die Hoffnung stirbt zuletzt... Jede Woche stolpere ich mehrmals über VoIP-Bugs, die ich hier im Forum auf dem Silbertablett serviert habe, für die sich aber niemand interessiert. Einfaches Beispiel: hängende Calls bei ausgehendem Ruf und 2 Minuten klingeln lassen. Weiteres: Der VCM ist nicht ansatzweise stabil gegenüber Paketverlusten, wie sie bei UDP naturgemäß auftreten können. Geht ein UDP-Paket hops, geht alles den Bach runter, der VCM fängt das verbindungslose UDP nicht auf. Und das im Jahr 12 nach Einführung von VoIP. Damit werden alle Versuche WLAN-Telefonie (z. B. mit App auf dem Smartphone) zu installieren bereits im Keime erstickt. Ich frage mich regelmäßig, wie fildercom das hinbekommen hat, dass das zuverlässig funktioniert. Genauso zuverlässig, wie ein normales DECT-Telefon.

[fildercom]

Ich frage mich regelmäßig, wie fildercom das hinbekommen hat, dass das zuverlässig funktioniert. Genauso zuverlässig, wie ein normales DECT-Telefon.

Es läuft prima. Ich nutze aber auch keine App, sondern die Ascom i62-Telefone und das QoS habe ich lückenlos auf allen beteiligten Komponenten sauber konfiguriert.

[Jirka]

Und machen die SIP per UDP oder per TCP?
Davon unabhängig bleibt das Problem WAN-seitig trotzdem, schließlich habe ich nicht überall SIP-Trunks, die SIP per TCP machen. QoS kann ich WAN-seitig auch nur begrenzt sicherstellen.

[fildercom]

Und machen die SIP per UDP oder per TCP?

Das ist UDP, wie gehabt, Port 5060. Allerdings hängt bei mir ja eine be.IP Plus als PBX zwischen dem VCM und den Telefonen. WAN-seitig ist QoS so eine Sache, da hat man kaum einen Einfluss. Allerdings kann man LAN-seitig schon vieles tun... Ich nutze dazu die DSCP-Werte CS5 für SIP und CS6 für RTP. Die Switches sind alle so eingestellt, dass sie die mit diesen Werten markierten Pakete dementsprechend in die korrekten Warteschlangen eingruppieren. Bei den Juniper-Switches kann man da noch viel mehr tun, als bei den GS-23xx. Auf "Best Effort" verlasse ich mich jedenfalls nicht...

[Jirka]

Allerdings hängt bei mir ja eine be.IP Plus als PBX zwischen dem VCM und den Telefonen.

Allerdings? Na Du bist ein Witzbold... Damit sind Deine WLAN-SIP-Clients gar nicht am VCM registriert und das Problem kann bei Dir gar nicht auftreten, weil die Situation eine ganz andere ist. Auf dem Stück Ethernet-Kabel zwischen be.IP und LANCOM treten üblicherweise keine Paketverluste auf... Na wenigstens weiß ich jetzt, wieso es denn bei Dir geht...

[fildercom]

Auf dem Stück Ethernet-Kabel zwischen be.IP und LANCOM treten üblicherweise keine Paketverluste auf... Na wenigstens weiß ich jetzt, wieso es denn bei Dir geht...

MOMENT: Zwischen 2x LANCOM und be.IP plus ist deutlich mehr dazwischen:
Mehrere Managed Switches und auch noch Koax Bridges (devolo dLAN 500 AVpro UNI, auf den aber auch entsprechende QoS-Regeln bestehen).

[Koppelfeld]

WAN-seitig ist QoS so eine Sache, da hat man kaum einen Einfluss.Allerdings kann man LAN-seitig schon vieles tun... Ich nutze dazu die DSCP-Werte CS5 für SIP und CS6 für RTP.

Bedingt durch die unsymmetrischen Anbindungen, wie sie vorherrschen, ist gerade der Upstream kritisch - und auf den hast Du Einfluß.
Und den solltest Du auch nutzen.

Im LAN ist es völlig wumpe, wie Dein Switch eingestellt ist. Jedes SIP-Endgerät speichert für mindestens 40 ms Pakete vor. Wann hattest Du im LAN jemals eine Rondtripzeit von 80 ms? Obwohl, mit 3Com ist ja vieles möglich - aber die gibt es gottseidank nicht mehr.

Wenn Du dir stattdessen etwas gutes tun willst, dann verbinde die Switches untereinander mit einem aggregierten Mehrfachlink, beispielsweise mit LACP. So haben die kleinen VoIP-Paketchen die Chance, eine "Überholspur" zu nutzen.

[fildercom]

Wenn Du dir stattdessen etwas gutes tun willst, dann verbinde die Switches untereinander mit einem aggregierten Mehrfachlink, beispielsweise mit LACP. So haben die kleinen VoIP-Paketchen die Chance, eine "Überholspur" zu nutzen.

Überall, wo es technisch möglich ist, habe ich die Switches mit 2 x 1 GbE per LACP verbunden, demnächst gibt es stellenweise sogar ein Upgrade auf 2 x 10 GbE

[Dr.Einstein]

Die 10.20 RU1 ist draussen, konntest du schon testen?

Gruß Dr.Einstein

[fildercom]

Die 10.20 RU1 ist draussen, konntest du schon testen?

Gruß Dr.Einstein

Ich habe es gesehen und habe inzwischen auch zwei Daily Builds erhalten. Ich muss morgen oder Samstag testen und werde dann über die Ergebnisse berichten...

[fildercom]

So, ich habe es mit der 10.20 RU1 und den beiden Daily Builds getestet:
Das Problem besteht leider weiterhin. Ich habe das auch an den Support nochmal so weitergegeben.

Ich hoffe sehr, dass hier noch eine Lösung gefunden werden kann.

Viele Grüße
fildercom.

[fildercom]

Ich hatte heute eine erneute TeamViewer-Session mit dem Support.
Wir konnten das Problem insoweit eingrenzen, dass der Router mit LCOS 10.20 sämtliche Datenpakete, die aufs WAN-Interface gehören, statt dessen auf LAN-1 und damit auf seinen VRRP-Partner leitet. Erste nach dem manuellen Trennen und automatischen Neuverbinden der PPPoE-Verbindung funktioniert es normal.

Der Fehler ist daher vermutlich irgendwo im VRRP zu suchen, so zumindest meine momentane Vermutung.

Sobald es Neuigkeiten gibt, werde ich es hier posten.

Gruß
fildercom.

[Dr.Einstein]

Hmm, würde zumindest erklären, wieso ich das Problem bei mir (noch) nicht nachstellen konnte. Evtl. hängt sich da was auf, wenn er aufgrund des 2. Routers in den Reconnect Zustand gehen will. Ist nur ein Router am Netz, kommt das VRRP ja direkt hoch ohne Wartezeit... Guter Ansatzpunkt

Gruß Dr.Einstein

[backslash]

Hi fildercom,

das VRRP-Problem ist mittlerweile gefixt - ab 10.20.0290... Am besten wendest du dich an den Support und fragst nach einer aktuellen alpha...

Gruß
Backslash