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

[cpuprofi]

Hallo an Alle,

ich möchte mich nun auch mal zu diesem Thema äußern.

Ich weiß ja nicht, wer dieses "Verhalten" des VCM's auf dem Gewissen hat (AWI oder BEKI), welches weder praxistauglich noch "SIP Connect" konform ist.

Ich hatte damals mit AWI eine sinnvollere Register Methode entwickelt, welche praxistauglicher war und gut funktionierte (auch wenn ich die Registerzeiten für die erste Minute und die der nachfolgenden Minuten umgedreht hätte [erst 6 Sekunden, dann 10 Sekunden]).

Der Fehler von damals war:

Code: Alles auswählen

Ist das Passwort in der SIP-Leitung vom LANCOM falsch hinterlegt worden, so
antwortet der Provider Dus.net auf das (zweite authorisierte) REGISTER des
LANCOMs mit 401 Unauthorized.
Daraufhin sendet der LANCOM sofort wieder ein REGISTER an den Provider, was
dieser wiederum mit 401 Unauthorized ablehnt.
Dieses Spiel geht immer so weiter, so dass innerhalb weniger Sekunden
hunderte unveränderte REGISTER vom LANCOM an den Provider gesendet werden.
In dem Fall von Dus.net wird das als DoS-Attacke interpretiert und der
Provider sperrt daraufhin die sendende IP-Adresse nach dem 39. "401
Unauthorized".

Die Lösung war dann folgende:

Code: Alles auswählen

In der 9.10 RC2 gibt es eine Änderung.
Das Register läuft nun folgendermaßen ab:

Das LCOS sendet in der ersten Minute alle 10 Sek. ein REGISTER.
Nach der ersten Minute versucht er es dann 10mal pro Minute
Anschließend sendet er das REGISTER immer alle 5 Minuten, bis die Anmeldung
erfolgreich war, oder es zu einer Konfigurationsänderung der SIP-Leitung
gekommen ist.

Leider wurde dieses nicht beibehalten...

Die nun implementierte Lösung ist mit einer endgültigen Registerzeit von 30 Minuten weit über den im "SIP Connect" geforderten 960 Sekunden hinaus! Wenn Lancom sich schon auf diesen "Standard" beruft, dann sollte man es auch schon "richtig" machen...

Wobei ich den im "SIP Connect" vorgeschriebenen "Standard" für praxisuntauglich halte und es besser wäre eine sinnvollere und praxistauglichere Lösung in dem VCM zu implementieren.

Unabhängig davon bleibt der VCM beim Wechsel zu oder von einer WAN-Backupverbindung regelmäßig auf der falschen (alten) WAN-Verbindung hängen, was mit dem Registerverhalten des VCM für Kunden, die auf eine funktionierende Telefonie angewiesen sind (Thema: Notruf ) katastrophale Folgen hat!

Auch ist die VCM/Firewall Problematik (einseitige Sprachverbindung nach Weiterleitung) bei IPv6 auch nach fast einem Jahr ( ) noch immer nicht gelöst...

Grüße
Cpuprofi

[awi]

Hallo zusammen,

die letztlich großen Zeiten kommen durch einen Modus zustande, der im RFC 5626 beschrieben ist
und von einem 'großen Telekomanbieter' gefordert wurde.
Es gefällt mir auch nicht besonders und es sind möglicherweise auch noch Fehler enthalten,
bzw. Verbesserungspotential um schneller wieder aus dem Modus herauszukommen.
Andererseits könnte man auch über ein Konfigurationsmöglichkeit nachdenken, so dass man einen anderen Modus fährt.
Wenn man allerdings sieht, wie überladen die Sip-Leitungskonfiguration schon ist, dann schreckt man da auch eher vor zurück.

Ich bin für Verbesserungsvorschläge offen, inwieweit
diese dann umsetzbar sind, muss sich zeigen.

Wegen der 180 Sekunden im Falle des VPN:
Dort war ja die WAN-Verbindung down, bevor der VPN neu aufgebaut wurde.
Das heißt ein Reset des Backoff-Timers sollte im Falle eines Connection-Down
gefahrlos gemacht werden können und bei einem Neustart dann nicht direkt bei 180 Sekunden starten. (Zumindest bei einer 10.12)

Andere Versionen verhalten sich hier anders, da es in diesem Bereich
einige Änderungen gab und auch noch geben wird.

Gruß
awi

[fildercom]

Hallo zusammen,

ich muss das Thema aus aktuellem Anlass nochmals nach oben holen. Ich habe heute unsere beiden 1781VA auf LCOS 10.20 anheben wollen. Der erste Router mit dem VDSL 50 hat auch keinerlei Probleme (am GK-Anschluss mit fester IP), der zweite Router mit dem ADSL2+ (am GK-Anschluss mit dynamischer IP) kann die SIP-Leitungen nicht mehr registrieren. Dabei spielt es keine Rolle, ob ich Port 5060 vorgebe oder ein DNS SRV Lookup mit Port 0 durchführen lasse.

Im Trace sieht das dann so aus:

Code: Alles auswählen

[Callmanager] 2018/10/24 18:17:51,284  Devicetime: 2018/10/24 18:17:50,971 [SIP-Provider] : 0711XXXXXX: RegisterTimeout: isNotAvailable:no, TimerExpired:yes, this:07d2e600

[Callmanager] 2018/10/24 18:17:51,284  Devicetime: 2018/10/24 18:17:50,971 [SIP-Provider] : 0711XXXXXX: RegisterTimeout:get backoff status: 3

[Callmanager] 2018/10/24 18:17:51,284  Devicetime: 2018/10/24 18:17:50,971 [SIP-Provider] : 0711XXXXXX: RegisterTimeout: Set backoff timer

[Callmanager] 2018/10/24 18:17:51,284  Devicetime: 2018/10/24 18:17:50,971 [SIP]: cRegBackoffState::resetNoAnswer  -- Status: 3

[Callmanager] 2018/10/24 18:17:51,284  Devicetime: 2018/10/24 18:17:50,971 [SIP-Provider] : 0711XXXXXX: RegisterTimeout: eNaRegister

[Callmanager] 2018/10/24 18:17:51,284  Devicetime: 2018/10/24 18:17:50,971 [SIP-Provider] : 0711XXXXXX: Register: CallId:+49711XXXXXX-tel.t-online.de-XXXXXXXX@00a057XXXXXX

[Callmanager] 2018/10/24 18:17:51,284  Devicetime: 2018/10/24 18:17:50,971 [SIP-Provider] : 0711XXXXXX: Register: repeating REGISTER message 

Auch nach über einer Stunde bleibt das so und die Leitungen werden nicht registriert.

Nun habe ich das ältere Firmware-Image wieder aktiviert (LCOS 10.12 RU9) und die Leitungen werden SOFORT registriert!

Zuerst hatte ich die gestern bei uns durchgeführte BNG-Migration im Verdacht (hatte Easy Login deaktiviert), aber auch nach erneutem Aktivieren von Easy Login klappt es mit LCOS 10.20 nicht, mit LCOS 10.12 dagegen klappt es problemlos.

Irgendwo muss im LCOS 10.20 ein Problem bei der SIP-Registrierung sein, allerdings nicht generell, da es am anderen Anschluss mit EXAKT identischer Konfiguration des VCM ja auch einwandfrei funktioniert.

Was kann ich tun? Soll ich ein Ticket öffnen? Oder ist das Problem bereits bekannt und im RU1 (welches vielleicht in den nächsten Wochen ja erscheint) gefixt?

Vielen Dank und viele Grüße
fildercom.

[Dr.Einstein]

Hi fildercom,

idealerweise das SIP Registerpaket vor und nach dem Update hier posten (evt. mit den ersten Antwortpaketen, trace # sip-packet).

Gruß Dr.Einstein

[fildercom]

@ Dr.Einstein:
Gut, werde ich nachreichen.

[fildercom]

Hallo Dr.Einstein und All Others,

ich habe die Traces des SIP Packets erstellt.

Mit LCOS 10.12, bei dem alles normal klappt, sieht das so aus:

Code: Alles auswählen

[SIP-Packet] 2018/10/25 19:46:35,111 [Packet]:
Sending datagram (613 Bytes) from 46.XXX.XXX.XXX:8917 to 217.0.XX.XXX:5060 using UDP (RtgTag 0):
REGISTER sip:tel.t-online.de SIP/2.0\r\n
Via: SIP/2.0/UDP 46.XXX.XXX.XXX:8917;branch=z9hG4bK-a9588950-999992ff;rport\r\n
From: "+49711XXXXXX"<sip:+49711XXXXXX@tel.t-online.de>;tag=1897099781--1045128361\r\n
To: "+49711XXXXXX"<sip:+49711XXXXXX@tel.t-online.de>\r\n
Call-ID: +49711XXXXXX-tel.t-online.de-6ca70c1b@00a0571bae44\r\n
CSeq: 204 REGISTER\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS, PRACK, UPDATE, SUBSCRIBE\r\n
Max-Forwards: 70\r\n
Contact: <sip:+49711XXXXXX@46.XXX.XXX.XXX:8917;transport=UDP>\r\n
Expires: 480\r\n
User-Agent: LANCOM 1781VA (over ISDN) / 10.12.0382 / 12.06.2018\r\n
Content-Length: 0\r\n
\r\n

Beim LCOS 10.20, welches keine SIP-Registrierung zulässt, sieht das so aus:

Code: Alles auswählen

[SIP-Packet] 2018/10/25 19:55:47,409 [Packet]:
Sending datagram (878 Bytes) from 192.168.XXX.XXX:8439 to 217.0.XX.XX:5060 using UDP (RtgTag 0):
REGISTER sip:tel.t-online.de SIP/2.0\r\n
Via: SIP/2.0/UDP 192.168.XXX.XXX:8439;branch=z9hG4bK-6184859c-db1c0d89;rport\r\n
From: "+49711XXXXXX"<sip:+49711XXXXXX@tel.t-online.de>;tag=1532091666--1295889230\r\n
To: "+49711XXXXXX"<sip:+49711XXXXXX@tel.t-online.de>\r\n
Call-ID: +49711XXXXXX-tel.t-online.de-1966b3c0@00a0571bae44\r\n
CSeq: 5 REGISTER\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS, PRACK, UPDATE, SUBSCRIBE\r\n
Max-Forwards: 70\r\n
Contact: <sip:+49711XXXXXX@192.168.XXX.XXX:8439;transport=UDP>\r\n
Expires: 480\r\n
User-Agent: LANCOM 1781VA (over ISDN) / 10.20.0175 / 27.09.2018\r\n
Authorization: Digest username="anonymous@t-online.de", realm="tel.t-online.de", algorithm=MD5, uri="sip:tel.t-online.de", nonce="E890DD165602D25B0000000062A52459",qop=auth, cnonce="ef4f11da77a788ed", nc=00000010, response="ded78c6237ca864b3eb2579b7d0bce6a"\r\n
Content-Length: 0\r\n
\r\n

Was mir dabei im Auge weh tut:
Warum setzt der LANCOM im LCOS 10.20 seine INTERNE IP-Adresse als Absender-Adresse in das SIP-Packet? Beim LCOS 10.12 steht da die externe dynamisch zugewiesene IP.
==> So kann das doch gar nicht funktionieren, der IMS-Server der Telekom wird solche Pakete nicht beantworten (können), da private IP-Adressen nicht ins öffentliche Netz gehören.

Oder wie siehst du/seht ihr das?

Außerdem fällt mir noch auf, dass der Abschnitt "Authorization" beim LCOS 10.12 nicht vorhanden ist, beim LCOS 10.20 hingegen schon. Eigentlich hat das bei den normalen Telekom-Tarifen (die kein SIP-Trunk sind) auch nichts zu suchen, da hier kein SIPS verwendet wird.

Tja, aber nun wieder zurück zu meinem Problem:
Habe ich die Ursache mit der IP bereits gefunden oder liegt es wo anders?

Wäre über jeden Tipp und Hinweis dankbar!

Viele Grüße
fildercom.

[Dr.Einstein]

Heyho,

du hast das Problem auf jeden Fall gefunden:

Code: Alles auswählen

Sending datagram (878 Bytes) from [u]192.168.XXX.XXX:8439[/u] to 217.0.XX.XX:5060 using UDP (RtgTag 0):

So kann das nicht funktionieren. Ich frag mich ehrlich gesagt wodurch das kommt. Kannst du evtl kurz beschreiben, wie bei dir die ARF Netze (inkl Tag und angezeigter Lanconfig Reihenfolge) aussehen + Routing Tabelle (Default Route(n) reichen) mit Tag.

Wenn ich's richtig aufm Schirm habe, hat LCOS 10.20 neuerdings die Möglichkeit, eine Loopback Adresse für die Quelle des Call Managers anzugeben (/Setup/Voice-Call-Manager/Lines/SIP-Provider/Line/Loopback-Address). Vielleicht ist hier was in der Implementierung schief gelaufen. Sieht so aus, dass du ein Case bei Lancom einkippen musst. Kann sein, dass ich bei meinen Prüfen auf das gleiche Problem treffen werden, dann würde ich die Sache vermutlich auch öffnen. Leider habe ich aber momentan ganz andere Sorgen als ein LCOS 10.20 bei meinen Kunden einzuführen, kA wann ich mal dazu kommen würde.

Gruß Doc

[fildercom]

So kann das nicht funktionieren. Ich frag mich ehrlich gesagt wodurch das kommt. Kannst du evtl kurz beschreiben, wie bei dir die ARF Netze (inkl Tag und angezeigter Lanconfig Reihenfolge) aussehen + Routing Tabelle (Default Route(n) reichen) mit Tag.

Klar, bitteschön (ist jetzt zwar vom Zustand während der funktionierenden 10.12 gemacht, sollte die 10.20 beim Upgrade aber 1:1 übernehmen):




Den Punkt

Code: Alles auswählen

/Setup/Voice-Call-Manager/Lines/SIP-Provider/Line/Loopback-Address

finde ich im Web-Interface bei der 10.20 allerdings nicht (auch nicht auf dem CLI).

Hast du eine Idee, was da los sein kann? Für mich sieht die Konfiguration ganz normal aus...

Gruß und danke
fildercom.

[Dr.Einstein]

0815 Konfiguration, paar ARFs, nackige Routing Tabelle. Traurig, dass sowas durch die Lancom QS fällt... Du müsstest jetzt halt ein Case öffnen mit den beiden Tracen und der exportierten Support Config.

Den Pfad für die Loopback findest du über die CLI oder den LCOS Menübaum der WebConfig. Aber du kannst da nix machen, du kannst ja schlecht eine dynamische WAN Adressen eintragen (klar, über Aktionstabelle und %a bla, aber wer macht schon sowas, kann nicht Sinn der Erfindung sein)

Gruß Dr.Einstein

[fildercom]

Ich habe jetzt ein Ticket erstellt und um höchste Priorisierung gebeten, da dieser Fehler wirklich eine Unmöglichkeit ist.

[Koppelfeld]

0815 Konfiguration, paar ARFs, nackige Routing Tabelle. Traurig, dass sowas durch die Lancom QS fällt...

Hallo,
Ich habe jetzt bestimmt 10 VCM mit 10.20 eingerichtet resp. von 10.0 migriert. Fünf davon mit Telekom - GK - Anschlüssen.

Und kann nur sagen, frei nach der lustigen Kurzgeschichte von Ershkine Caldwell, "You were perfectly fine".

Keine Fehler, bestes QoS, prima Durchsatz (570 MBit/s), jede Menge Features und VPNs -- alles funktioniert!
Übrigens auch der Telekom - Trunk.

Ich nehme schon fast an, ich wurde in ein Paralleluniversum geschleudert...

[Dr.Einstein]

@fildercom: kam schon etwas raus? Muss mich aktuell Koppelfeld anschließen, bei den ersten Updates, die ich durchgeführt habe, keine erkennbaren Probleme in Zusammenhang mit VoIP (inkl ARF etc), komisch ...

Gruß Dr.Einstein

[fildercom]

@fildercom: kam schon etwas raus? Muss mich aktuell Koppelfeld anschließen, bei den ersten Updates, die ich durchgeführt habe, keine erkennbaren Probleme in Zusammenhang mit VoIP (inkl ARF etc), komisch ...

Gruß Dr.Einstein

Hallo,
ja, der Support meinte auch, dass es keine allgemeinen Probleme gäbe. Ich sollte ein längeres Trace machen vor/nach dem Update und es zusenden. Das habe ich getan. Bisher habe ich noch kein Feedback bekommen. Alles sehr merkwürdig. Am zweiten Anschluss/Router mit fester IP-Adresse hier läuft es auch problemlos.

Gruß
fildercom.

[Jirka]

Hallo fildercom,

schön!
Nicht schön sind hingegen die geschwärzten Bereiche in dem Screenshot zu den ARF-Netzen. Warum? Das sind private Netze, ob Du da die 192.168.1.1 oder .2.1 oder .178.1 oder was weiß ich auch immer drin stehen hast, das ist doch datenschutzrechtlich völlig Banane. Man weiß nicht mehr von Deinen Netzen, wenn es nicht geschwärzt wäre, aber man könnte den Bug möglicherweise nachstellen.

Außerdem fällt mir noch auf, dass der Abschnitt "Authorization" beim LCOS 10.12 nicht vorhanden ist, beim LCOS 10.20 hingegen schon. Eigentlich hat das bei den normalen Telekom-Tarifen (die kein SIP-Trunk sind) auch nichts zu suchen, da hier kein SIPS verwendet wird.

Das hat mit SIPS aber nichts zu tun. Normal hat man die Authorization-Zeile immer mit drin. Der Trace ist ja nicht vollständig, sonst würde man beim nächsten Paket vom LANCOM-Router auch diese Zeile sehen. Normal sendet der LANCOM-Router sogar gleich die Zeile, hier hast Du sozusagen die Ausnahme erwischt, weil die letzte Authentifizierung fehl schlug oder die Daten für die Authentifizierung veraltet waren.

Viele Grüße,
Jirka

[fildercom]

Hallo Jirka,

danke für deine Antwort.

schön!

Was genau findest du schön? Den Fehler? Oder dass ich es an den Support gemeldet habe? Oder dass ich seitdem noch nichts vom Support gehört habe?

Nicht schön sind hingegen die geschwärzten Bereiche in dem Screenshot zu den ARF-Netzen. Warum? Das sind private Netze, ob Du da die 192.168.1.1 oder .2.1 oder .178.1 oder was weiß ich auch immer drin stehen hast, das ist doch datenschutzrechtlich völlig Banane. Man weiß nicht mehr von Deinen Netzen, wenn es nicht geschwärzt wäre, aber man könnte den Bug möglicherweise nachstellen.

Ja, ich bin etwas übervorsichtig geworden, nachdem ich 3 Jahre lang für den Datenschutzbeauftragten einer Dienststelle mit über 5.000 Mitarbeitern tätig war - da hat man zu viel gesehen und zu viel mitbekommen, wie es NICHT laufen soll.

Die Netze sind einfach durchgehend in der Art
192.168.1.0
...
192.168.4.0

Ich hoffe, dass das weiter hilft.

Viele Grüße und danke
fildercom.