LANCOM-Forum.de

Das inoffizielle Profi-Forum für LANCOM-User
Aktuelle Zeit: 25 Apr 2018, 00:24

Alle Zeiten sind UTC + 1 Stunde [ Sommerzeit ]




Ein neues Thema erstellen Auf das Thema antworten  [ 15 Beiträge ] 
Autor Nachricht
BeitragVerfasst: 03 Apr 2018, 00:43 
Offline
Benutzeravatar

Registriert: 03 Jan 2005, 14:39
Beiträge: 4010
Wohnort: Ex-OPAL-Gebiet
Hallo,

ich habe zwei recht ähnliche, für einen Kunden mit hohem Telefonieaufkommen relativ schwerwiegende Probleme:

1) Zum einen registriert sich eine SIP-Trunk/Gateway-Leitung über VPN erst nach "gefühlten Ewigkeiten" (3,5 Min.), z. B. nach Verbindungstrennung oder Bootvorgang.
2) Zum anderen registriert sich eine SIP-Trunk/Gateway-Leitung "ewig" (bis zu 30 Min.) nicht wieder, z. B. nach Ausfällen von Routern/Internetzugängen/Telefonanlage/Strom.

Die nachfolgenden Untersuchungen wurden auf einem 1783 vorgenommen mit Firmware 10.12-RU6. Das Problem tritt aber auch mit der 9.24 und anderen Routern mit All-IP/VCM auf. Um Zeitverschiebungen/-ungenauigkeiten auszuschließen wurde der automatische Zeitabgleich vorübergehend deaktiviert.

1) Eine der vielen sehr positiven Eigenschaften der All-IP-Option ist, dass der VCM nach Verbindungstrennungen (z. B. 24-h-Zwangstrennung, DSL-Synchronisationsverlust, kurze Ausfälle der Internetverbindung und sonstige Verbindungstrennungen) und nach Bootvorgängen (z. B. erforderlicher oder geplanter Neustart, Absturz/OS-Panic, Stromausfall) sehr schnell wieder einen funktionalen Betrieb gewährleistet. SIP-Leitungen sind meist zwei oder drei Sekunden nach Verbindungsherstellung wieder registriert, das kann keine Telefonanlage leisten, erst recht nicht bei dynamischer IP-Adresse oder ähnlichen, zwar selten vorkommenden, aber dann meist schwerwiegenden Randbedingungen. Mit einer SIP-Leitung, die über eine VPN-Verbindung zu registrieren ist, tut sich der VCM aber komischerweise sehr schwer. Und da sehe ich keinen Grund für, daher gehe ich von einem Bug aus. Im konkreten Fall baut in einer Filiale ein 1783 eine VPN-Verbindung in die Zentrale auf, wo die Telefonanlage steht. Das REGISTER über diese VPN-Verbindung passiert aber leider nicht schnell genug. Im Syslog (zu Lesen von unten nach oben; aufs Wesentliche gekürzt) kann man das schön nachvollziehen:

Code:
19:05:18 [VCM] SIP-Line SWYXGW-WAREN switched to status 'registered'
19:02:04 Login from 172.20.172.223 via Telnet-SSL
19:02:04 Login from 172.20.172.223 via Telnet-SSL
19:01:54 Successfully connected to peer RIS-HWI-CC
19:01:54 Successfully connected to peer HGW-7100P
19:01:50 Login from 172.20.172.223 via Telnet-SSL
19:01:50 Login from 172.20.172.223 via Telnet-SSL
...
19:01:48 [VCM] SIP-Line TELEKOM-222278 switched to status 'registered'
19:01:48 Successfully connected to peer HRO-9100P
19:01:46 Successfully connected to peer TELEKOM
19:01:46 local IP address for TELEKOM is 217.92.100.100, remote IP address is 217.0.117.226
...
19:01:38 [VCM] SIP-Line TELEKOM-222278 switched to status 'un-registered'
19:01:38 [VCM] SIP-Line TELEKOM-222278 switched to status 'generic failure'
19:01:38 Accounting list end
19:01:38 User: LANUSER-192.168.180.31  Peer: TELEKOM Rx(kB): 0  Tx(kB): 0  Time(s): 30 Conn: 0
...
19:01:38 User: LANUSER-192.168.180.235 Peer: TELEKOM Rx(kB): 0  Tx(kB): 0  Time(s): 45 Conn: 0
19:01:38 Accounting list start
19:01:38 Disconnected from peer TELEKOM: manual-disconnect
19:01:38 Disconnected from peer RIS-HWI-CC
19:01:38 [VCM] SIP-Line SWYXGW-WAREN switched to status 'un-registered'
19:01:38 Disconnected from peer HGW-7100P
19:01:38 last message repeated 3 times
19:01:38 User from 172.20.172.223 via Telnet-SSL logged out
19:01:38 [VCM] SIP-Line SWYXGW-WAREN switched to status 'generic failure'
19:01:38 Accounting list end
19:01:38 User: LANUSER-192.168.180.31  Peer: HRO-9100P Rx(kB): 1  Tx(kB): 1  Time(s): 10 Conn: 0
...
19:01:38 User: LANUSER-192.168.180.230 Peer: HRO-9100P Rx(kB): 3  Tx(kB): 1  Time(s): 33 Conn: 0
19:01:38 Accounting list start
19:01:38 Disconnected from peer HRO-9100P
19:01:38 VPN: Disconnect info for peer RIS-HWI-CC: physical-disconnected
19:01:38 VPN: Disconnect info for peer RIS-HWI-CC: physical-disconnected
19:01:38 VPN: Disconnect info for peer HGW-7100P: physical-disconnected
19:01:38 VPN: Disconnect info for peer HGW-7100P: physical-disconnected
19:01:38 VPN: Disconnect info for peer HRO-9100P: physical-disconnected
19:01:38 VPN: Disconnect info for peer HRO-9100P: physical-disconnected
19:01:30 Login from 192.168.180.2 via SSH

Zusammenfassung: 19:01:38 Uhr manuelle Verbindungstrennung, 19:01:46 Uhr Verbindung wieder aufgebaut, 19:01:48 Uhr VPN-Verbindung aufgebaut und normale SIP-Leitungen registriert, und erst 19:05:18 Uhr ist die SIP-Leitung zur Telefonanlage registriert - 3,5 Min. zu spät.

Im SIP-Packet-Trace ist nichts zu sehen, keine REGISTER-Versuche vor 19:05:18 Uhr. Im Callmanager-Trace sieht man warum. Da wird die Registrierung erst mal um 180 Sekunden verzögert und anschließend noch mal um weitere 30 Sekunden, zusammen 210 Sekunden oder eben 3,5 Minuten. Ich bin der Meinung, dass das ein Bug ist und bitte hiermit um einen Fix. Derzeit springt nach jeder derartigen Situation mein Monitoring an (dieses meldet nicht registrierte SIP-Leitungen nach 2 Minuten).
Callmanager-Trace:
Code:
19:01:38,086 [SWYXGW-WAREN Registrar Transport]: WAN connection "HRO-9100P" for line "SWYXGW-WAREN" is down!  SipLineTransport: 0x04b6abd0
19:01:38,086 [SIP-Provider] : SWYXGW-WAREN: connection down
19:01:38,089 [SIP-Provider] : SWYXGW-WAREN: stopRegistration: this:04b690e0, caller:01cd964c, registration:enabled, register_info:active
19:01:48,047 [SWYXGW-WAREN Registrar Transport]: WAN connection "HRO-9100P" for line "SWYXGW-WAREN" is up!  SipLineTransport: 0x04b6abd0
19:01:48,047 [SWYXGW-WAREN Registrar Transport]: Restarting in 180 seconds
19:04:48,047 [SWYXGW-WAREN Registrar Transport]: (Re)Starting with fixed IP address 172.20.172.223
19:04:48,047 [SWYXGW-WAREN Registrar Transport]: New restart backoff is 180 seconds
19:04:48,047 [SWYXGW-WAREN Registrar Transport]: New transport endpoint is 172.20.172.223:5060, transport state is "FixedIpBootstrapping"
19:04:48,048 [SIP-Provider] : SWYXGW-WAREN: registrar transport is ready
19:04:48,048 [SIP-Provider] : SWYXGW-WAREN: startRegistration: this:04b690e0, caller:01cdb92c, registration:enabled, register_info:NOT active
19:04:48,048 [SIP-Provider] : SWYXGW-WAREN: RegisterTimeout: isNotAvailable:no, TimerExpired:no, this:04b690e0
19:04:48,048 [SIP-Provider] : SWYXGW-WAREN: RegisterTimeout: Register finally failed  -  change to rfc 5626 mode  --  backoff status: 0
19:04:48,048 [SIP-Provider] : SWYXGW-WAREN: restartShortRegisterTimer -> time:30000, this:04b690e0, Caller:01cea900
19:04:48,048 [SIP-Provider] : SWYXGW-WAREN: processing pending messages -> registrar transport state:Ready, database is empty
19:04:48,048 [SIP-Provider] : SWYXGW-WAREN: No messages were pending!
19:05:18,048 [SIP-Provider] : SWYXGW-WAREN: RegisterTimeout: isNotAvailable:no, TimerExpired:yes, this:04b690e0
19:05:18,048 [SIP-Provider] : SWYXGW-WAREN: RegisterTimeout:get backoff status: 1
19:05:18,048 [SIP-Provider] : SWYXGW-WAREN: RegisterTimeout: Set backoff timer
19:05:18,048 [SIP-Provider] : SWYXGW-WAREN: RegisterTimeout: eNaUnregister
19:05:18,048 [SIP-Provider] : SWYXGW-WAREN: Unregister: CallId:LANCOM102-172.20.172.223-ed2c2d1f@00a0572e2d44
19:05:18,049 [SIP-Provider] : SWYXGW-WAREN: Unregister: created SIP call
19:05:18,049 [SIP-Provider] : SWYXGW-WAREN: processing pending messages -> registrar transport state:Ready, database has calls
19:05:18,049 [SIP-Provider] : SWYXGW-WAREN: restartShortRegisterTimer -> time:60000, this:04b690e0, Caller:01ceaa70
19:05:18,092 [SIP-Provider] : SWYXGW-WAREN: restartShortRegisterTimer -> time:500, this:04b690e0, Caller:01ceb4c4
19:05:18,593 [SIP-Provider] : SWYXGW-WAREN: RegisterTimeout: isNotAvailable:no, TimerExpired:yes, this:04b690e0
19:05:18,593 [SIP-Provider] : SWYXGW-WAREN: RegisterTimeout:get backoff status: 0
19:05:18,593 [SIP-Provider] : SWYXGW-WAREN: RegisterTimeout: Set backoff timer
19:05:18,593 [SIP-Provider] : SWYXGW-WAREN: RegisterTimeout: Start Timer F
19:05:18,593 [SIP-Provider] : SWYXGW-WAREN: RegisterTimeout: eNaRegister
19:05:18,593 [SIP-Provider] : SWYXGW-WAREN: Register: CallId:LANCOM102-172.20.172.223-ed2c2d1f@00a0572e2d44
19:05:18,593 [SIP-Provider] : SWYXGW-WAREN: Register: created SIP call
19:05:18,593 [SIP-Provider] : SWYXGW-WAREN: processing pending messages -> registrar transport state:Ready, database has calls
19:05:18,593 [SIP-Provider] : SWYXGW-WAREN: restartShortRegisterTimer -> time:1000, this:04b690e0, Caller:01ceaa70
19:05:18,640 [SIP-Provider] : SWYXGW-WAREN: restartShortRegisterTimer -> time:2000, this:04b690e0, Caller:01cea260
19:05:18,689 [SIP-Provider] : Line 'SWYXGW-WAREN' changed status to 'operable'
19:05:18,689 [SIP-Provider] : SWYXGW-WAREN: restartRegisterTimer -> MinExpiresTime:0, time:120000, this:04b690e0, Caller:01ceb14c


2) Ausfälle von Komponenten in der Telefonieinfrastruktur kann man nie ganz ausschließen, ich hatte in den letzten 2 Wochen durch zwei Stromausfälle und einen Aufall einer Telefonanlage einige Beispiele dafür, dass die Ausfälle durch den LANCOM-VCM noch erheblich vergrößert wurden bzw. manuelle Eingriffe notwendig wurden, um zügig wieder einen funktionalen Zustand herzustellen. Und wer jetzt sagt, das hätte man durch eine USV verhindern können, der irrt. Selbst die Telekom brauchte z. B. nach einem einsekündigen Stromausfall 15 Min. bis eine Company-Connect-Leitung wieder funktional war. Betrachtet wird jetzt der gleiche Standort wie bei 1). Fällt auf dem Weg zur Telefonanlage in der Zentrale irgendwas ein wenig länger aus (oder werden die zentralen Server gewartet), so kommt es leider vor, dass die SIP-Trunk-Leitung "ewig" braucht, um wieder registriert zu sein. Ich weiß noch genau, als damals das Verhalten geändert wurde. Das passierte seinerzeit durch eine Bugmeldung von "Cpuprofi", der wiederum von einem SIP-Provider die durchaus berechtigte Kritik zu hören bekam, ein LANCOM-Router würde SIP-Provider im Fehlerfall mit sekündlichen REGISTERs zuspammen und damit fluten. Das war in der Tat wie gesagt verbesserungswürdig und wurde dann ja auch geändert. Das seitdem vorliegende Ergebnis ist allerdings auf Kosten von Zuverlässigkeit und Verfügbarkeit gegangen. Erst recht, wenn man eine SIP-Leitung bei seiner eigenen Telefonanlage registrieren will und nicht bei einem Provider. Davon unabhängig halte ich aber ein REGISTER in Abständen von sage und schreibe bis zu 30 Minuten für nicht praxistauglich! RFC 5625 hin oder her, das geht gar nicht. Und wenn man mal überlegt, dass das ein UDP-Paket ist, was auch mal verschütt gehen kann, wenn es ganz schlecht läuft, dann werden aus 30 Minuten schnell bis zu 60. Und es kann auch nicht sein, dass derartige Situationen mit Cron-Tabellen-Einträgen oder Scripten abgefangen werden müssen. Ich habe mir also mal angeschaut, was passiert, wenn ein REGISTER vom LANCOM-Router verlustig geht. Wann kommt das nächste? Wann das übernächste? Usw. Herausgekommen ist (für diesen Standort mit REGISTER über VPN) folgende Excel-Tabelle:

Code:
Echtzeit   Zeit       Zeitdiff.   Versuch Nr.
---------------------------------------------
13:35:42   00:00:00   00:00:00             1
13:35:43   00:00:01   00:00:01             2
13:35:45   00:00:03   00:00:02             3
13:35:49   00:00:07   00:00:04             4
13:35:53   00:00:11   00:00:04             5
13:35:57   00:00:15   00:00:04             6
13:36:01   00:00:19   00:00:04             7
13:36:05   00:00:23   00:00:04             8
13:36:09   00:00:27   00:00:04             9
13:36:13   00:00:31   00:00:04            10
13:39:44   00:04:02   00:03:31            11
13:40:44   00:05:02   00:01:00            12
13:42:44   00:07:02   00:02:00            13
13:46:44   00:11:02   00:04:00            14
13:54:44   00:19:02   00:08:00            15
14:10:44   00:35:02   00:16:00            16
14:40:44   01:05:02   00:30:00            17
15:10:44   01:35:02   00:30:00            18
15:40:44   02:05:02   00:30:00            19
16:10:44   02:35:02   00:30:00            20


Ich bin wie gesagt der Auffassung, dass es auch nach einem größeren Ausfall oder Problem beim Provider selbst bei einem kleinen Kunden nicht sein kann, dass die Telefonie dann noch 30 Min. braucht, bis sie wieder funktioniert. Ein derartiges Intervall darf meiner Ansicht nach bei einem Hersteller wie LANCOM nicht über 10 Min. angesetzt werden. Anders ist es, wenn vom Provider eine Rückantwort kommt, die weitere Versuche unsinnig macht (z. B. Fehler bei der Registrierung). In diesem Fall hier rede ich aber davon, dass überhaupt keine Antwort auf das REGISTER kommt, weil z. B. der Weg dorthin gestört ist oder der SIP-Server noch nicht richtig arbeitet. Bei meiner eigenen Telefonanlage (also ich meine die meiner Kunden) würde ich diesen Maximalwert von 30 Min. gerne einstellbar haben, um so z. B. das Intervall auf max. 2 Minuten oder noch weniger, z. B. eine Minute, reduzieren zu können. Das halte ich auch keinesfalls für eine Belastung, schließlich sind die UDP-Pakete nicht groß, da gehen ganz andere Sachen über das Internet. Und als Feature-Wunsch betrachte ich es auch nicht, eher als Bugbeseitigung bzw. Nachbesserung zur damaligen Bugbeseitigung.

Betrachtet man die Tabelle genauer, stellt man auch Unregelmäßigkeiten fest, die meiner Ansicht nach so nicht beabsichtigt sind. Bis zum 10. REGISTER-Versuch ist ja noch alles in Ordnung - sehr gut. Danach wird das REGISTER komplett abgebrochen (sieht man im Callmanager-Trace) und neu gestartet - blöderweise wie bei 1) wieder mit 180 + 30 Sekunden Verzögerung. Gleicher Bug?! Wenn also der Ausfall 31 Sekunden oder mehr beträgt, dauert es schon mal 3,5 Min. bis auch die Telefonie wieder geht. Hat man die Schwelle von 35 Minuten überschritten, wird es richtig ernst. Dann dauert es sage und schreibe bis zu 30 Min. bis ein neues REGISTER angestoßen wird. Das habe ich über mein Monitoring so auch festgestellt, konnte mir aber gar nicht erklären, wodran das liegen soll. Jetzt weiß ich es.

Abschließend noch kurz ein Standort mit CompanyConnect-Leitungen in die Zentrale, d. h. der 1783, der den SIP-Trunk aufnimmt, registriert die SIP-Trunk-Leitung zur Telefonanlage in der Zentrale übers LAN (lokales Routing zum 9100+) und baut somit nicht selber die VPN-Verbindung auf. Man sieht, dass es dann anders läuft, das "3,5-Min.-Problem" ist zumindest da schon mal nicht da. Das grundsätzliche Problem bleibt aber das gleiche.

Code:
Echtzeit   Zeit       Zeitdiff.   Versuch Nr.
---------------------------------------------
23:36:04   00:00:00   00:00:00             1
23:36:05   00:00:01   00:00:01             2
23:36:07   00:00:03   00:00:02             3
23:36:11   00:00:07   00:00:04             4
23:36:15   00:00:11   00:00:04             5
23:36:19   00:00:15   00:00:04             6
23:36:23   00:00:19   00:00:04             7
23:36:27   00:00:23   00:00:04             8
23:36:31   00:00:27   00:00:04             9
23:36:35   00:00:31   00:00:04            10
23:37:34   00:01:30   00:00:59            11
23:38:34   00:02:30   00:01:00            12
23:40:34   00:04:30   00:02:00            13
23:44:34   00:08:30   00:04:00            14
23:52:34   00:16:30   00:08:00            15
00:08:34   00:32:30   00:16:00            16
00:38:34   01:02:30   00:30:00            17
01:08:34   01:32:30   00:30:00            18
01:38:34   02:02:30   00:30:00            19
02:08:34   02:32:30   00:30:00            20

(Die letzten 3 Zeilen habe ich jetzt mal freizügig ergänzt, ich wollte heute noch ins Bett...)

Vielen Dank und viele Grüße,
Jirka

_________________
13 Jahre LANCOM-Forum — 13 Jahre Kompetenz in Sachen LANCOM.


Nach oben
 Profil  
 
BeitragVerfasst: 11 Apr 2018, 18:29 
Offline

Registriert: 12 Jan 2010, 15:10
Beiträge: 1829
Wohnort: Berlin
Hi Jirka,

laut SIP Connect 1.1 müssten sich die Zeiten zwischen den Versuchen jedes Mal verdoppeln bis zu einem Maximum von 960 Sekunden. Komische Implementation...

Gruß Dr.Einstein


Nach oben
 Profil  
 
BeitragVerfasst: 11 Apr 2018, 22:23 
Offline
Benutzeravatar

Registriert: 03 Jan 2005, 14:39
Beiträge: 4010
Wohnort: Ex-OPAL-Gebiet
Danke. Wie ich schon schrieb, interessiert mich das nicht. Der Standard ist doch völlig praxisfern. Da kommen wir nie wieder an die Zuverlässigkeit von ISDN ran. Da steht aber auch irgendwo, dass man den Max-Wert einstellbar machen kann. Eine halbe Stunde geht schlicht gar nicht. Das nimmt mir kein TÜV ab. Selbst die Fahrstuhl-Notruf-Zentrale hat mir gestern erzählt, dass sie eine dauerhafte Verfügbarkeit benötigen. Habe ich gleich gesagt das gibt es nicht mehr. Na ja, ich hoffe, dass seitens LANCOM da ein Einsehen kommt, sonst baue ich, ich glaube das mache ich gleich noch, wenn ich zu Hause bin, ein entsprechendes Script.

_________________
13 Jahre LANCOM-Forum — 13 Jahre Kompetenz in Sachen LANCOM.


Nach oben
 Profil  
 
BeitragVerfasst: 11 Apr 2018, 23:28 
Offline

Registriert: 12 Jan 2010, 15:10
Beiträge: 1829
Wohnort: Berlin
Deine Aussage ist aber auch praxisfern bzw. Wunschdenken. Skalier mal die providerseitigen E-SBCs für die Menge an Registers, auch unter der Annahme, dass SIP over TCP / TLS immer stärken vertreten sein werden. Es gab eine kurze Zeit, wo die Telekom 300 Sekunden Register erlaubt hatte. Danach ist fast das gesamte Telefonie-Netz zusammengebrochen, weil die SBCs einfach nicht mehr hinterher gekommen sind (finde leider gerade den Artikel dazu nicht). Und das waren noch Zeiten, wo über 99% UDP SIP war. Klar, man kann jetzt auf die Provider schimpfen, sollen die halt auf einen SBC weniger Kunden rauflassen, aber wer trägt dann die Rechnung? Und ist die Sache dann überhaupt noch stabil, wenn statt k.A. 150 SBC 1500 SBCs im Providernetz verteilt sind?

Also ich kann beide Seiten nachvollziehen: Kunde will schnell wieder erreichbar sein (und durch evtl NAT-Probleme so oft wie möglich 'hallo' sagen), Provider will realistisches Kosten/Nutzen-Verhältnis + Netzstabilität haben. Ist halt alles kein leitungsbezogenes ISDN mehr, die Zeiten sind vorbei. Und ehrlich gesagt leben diese ganzen Fahrstuhl-Notruf-Firmen, Einbruchmeldeanlagen (=VDS) auch hinterm Mond. Wie lange die gebraucht haben, um überhaupt mal zu erkennen, das Analog/ISDN von allen Providern abgekündigt wurde. Teilweise wurden ja sogar jahrelang bei GSM Steine in den Weg gelegt. Hatte letztens erst einen Tankstellenverband, wo die Versicherung nicht mitspielen wollte, die haben weiterhin auf ISDN gepocht. Selbst MPLS als Unterbau haben die als Lösung nicht akzeptiert obwohl von der Verfügbarkeit laut AGBs besser als ISDN. Jetzt hat die Versicherung für den Kunden die VDS Klausel rausgenommen, weil die selbst gemerkt haben, wie veraltet das ganze Zeugs ist.

(was alles nichts daran ändert, dass das Lancom Verhalten unschön ist)

Gruß Dr.Einstein


Nach oben
 Profil  
 
BeitragVerfasst: 12 Apr 2018, 16:42 
Offline
Benutzeravatar

Registriert: 03 Jan 2005, 14:39
Beiträge: 4010
Wohnort: Ex-OPAL-Gebiet
Hallo Dr. Einstein,

Dr.Einstein hat geschrieben:
Deine Aussage ist aber auch praxisfern bzw. Wunschdenken.

da gebe ich Dir durchaus Recht. Aber ich gehe mit überzogenen Vorstellungen in die Verhandlung (darf man hier eigentlich gar nicht schreiben), wenn dann ein Kompromiss von 5 Min. bei rauskommt, habe ich eigentlich alles erreicht, jedenfalls wäre damit die Zeit, bis alles wieder funktional ist, um bis zu 83,3 % reduziert (für den Fall, dass nur noch alle 30 Min. registriert wird).
Dazu kommt, dass mir die Sache ja gar nicht nicht zur Providerseite hin auffiel, sondern intern zur eigenen Telefonanlage. Und genau das habe ich so auch oben geschrieben. Deine Argumentation ist also schön und gut, und ich stimme Dir natürlich auch zu, dass man beide Seiten bedenken/betrachten muss, trifft aber nicht zu, wenn der LANCOM-Router sich intern irgendwo registrieren soll oder am LANCOM der Zentrale.

Dr.Einstein hat geschrieben:
Skalier mal die providerseitigen E-SBCs für die Menge an Registers, auch unter der Annahme, dass SIP over TCP / TLS immer stärken vertreten sein werden. Es gab eine kurze Zeit, wo die Telekom 300 Sekunden Register erlaubt hatte. Danach ist fast das gesamte Telefonie-Netz zusammengebrochen, weil die SBCs einfach nicht mehr hinterher gekommen sind (finde leider gerade den Artikel dazu nicht). Und das waren noch Zeiten, wo über 99% UDP SIP war. Klar, man kann jetzt auf die Provider schimpfen, sollen die halt auf einen SBC weniger Kunden rauflassen, aber wer trägt dann die Rechnung?

Die Rechnung wird mit dem Geld beglichen, was durch den Wegfall der ISDN-Infrastruktur eingespart wird. Und dazu kommt, dass ein Kunde mit SIP-Trunk und mehreren Sprachkanälen, der mit CompanyConnect und anderen Anschlüssen mal locker 2.000 EUR im Monat an die Telekom zahlt, dass da die Frage, wer dann die Rechnung trägt, ja wohl nicht mehr gestellt werden sollte.

Dr.Einstein hat geschrieben:
Und ehrlich gesagt leben diese ganzen Fahrstuhl-Notruf-Firmen, Einbruchmeldeanlagen (=VDS) auch hinterm Mond.

Genau.

Dr.Einstein hat geschrieben:
was alles nichts daran ändert, dass das Lancom Verhalten unschön ist

Danke.
Wenn man das als Kompromiss konfigurierbar macht (meinetwegen auch nicht in LANconfig), oder aber die Maximalzeit auf die ehemalige Expires-Time begrenzen würde und wenn die nicht da ist, meinetwegen 5 Minuten ansetzt, dann dürfte hier kein Provider zusammenbrechen, zumal erstens LANCOMs ja nun immer noch nicht in einer solchen Fülle existieren, dass mehr als ein Viertel der Anschlüsse (nur den Business-Bereich betrachtet) mit LANCOMs ausgestattet sind und zweitens vor dem letzten Fix, wie ich mir von Cpuprofi sagen lassen musste, nicht sekündlich REGISTER vom LANCOM abgeschickt wurden, nein millisekündlich, d. h. jede Sekunde je nach LANCOM (CPU) und Internetanschluss (Bandbreite) bis zu mehrere hundert REGISTER je Sekunde verschickt wurden und das hat niemanden gestört. (Na ja, bis auf den einen Provider, wo die Sache aber auch nur aufgefallen ist, weil Cpuprofi ein REGISTER-Problem zur Klärung eingereicht hatte.)

Was macht die Telekom denn in den TRs für Vorgaben, was die Zeitspanne für ein erneutes REGISTER betrifft, wenn es keine Antwort seitens des Providers gibt?

Vielen Dank und viele Grüße,
Jirka

_________________
13 Jahre LANCOM-Forum — 13 Jahre Kompetenz in Sachen LANCOM.


Nach oben
 Profil  
 
BeitragVerfasst: 12 Apr 2018, 20:08 
Offline

Registriert: 20 Nov 2013, 10:17
Beiträge: 711
Hallo,
Jirka hat geschrieben:
Dr.Einstein hat geschrieben:
... auch unter der Annahme, dass SIP over TCP / TLS immer stärker vertreten sein werden ...

"Eigentlich" ist der Gedanke krude, SIP über UDP zu fahren, aber die Leute haben sich etwas dabei gedacht. Re-Registrierung bei QSC, Sipgate oder DTST: Weniger als drei Sekunden.
Zitat:
Aber ich gehe mit überzogenen Vorstellungen in die Verhandlung

Und damit macht Du dich schuldig. Du hast dem Endkunden etwas versprochen, über das Du noch "verhandelst". Das kann nicht seriös sein. Es gibt wirklich Menschen, die sind so dämlich und lassen sich jeden Scheiß erzählen, nimm' die "Grünen". Du gehörst aber quasi zur Komplementärmenge der Grünen (Burali-Forti und Cantor lassen schön grüßen) und *weißt*, was Du tust.

Und da wäre es sinnvoll, nur Konstellationen einzusetzen, die auch lauffähig sind.

Du kannst technische Probleme nicht "politisch" lösen -- und auch keine "politischen" technisch.


Nach oben
 Profil  
 
BeitragVerfasst: 12 Apr 2018, 23:53 
Offline
Benutzeravatar

Registriert: 03 Jan 2005, 14:39
Beiträge: 4010
Wohnort: Ex-OPAL-Gebiet
Hallo Koppelfeld,

Koppelfeld hat geschrieben:
Re-Registrierung bei QSC, Sipgate oder DTST: Weniger als drei Sekunden.

aus dem Urwald mit Satellitenanbindung oder wie?

Koppelfeld hat geschrieben:
Du hast dem Endkunden etwas versprochen, über das Du noch "verhandelst".

Nö, habe ich nicht. Wir, also der Kunde und ich, stellen nur fest, was die Praxis zeigt. Und wenn man das kritisch hinterfragt und genauer untersucht, dann zeigen sich derartige Sachen.

Koppelfeld hat geschrieben:
Und da wäre es sinnvoll, nur Konstellationen einzusetzen, die auch lauffähig sind.

Mein Script läuft! Und zwar mit nur einer Zeile mehr (zwei Befehle hintereinander, für jede SIP-Leitung einer; die SIP-PBX-Leitung funktioniert leider nicht, aber die ist auch nicht so schlimm, das sind nur die analogen Ports am LANCOM oder mal ein ISDN-Port, der an der Telefonanlage registriert wird). Das ist geradezu perfekt.

Aber noch mal zu Deinen weniger als drei Sekunden: Ein REGISTER geht normal mit 60..90 ms durch. Mit Unauthorized-Zwischenschritt. Also hin, zurück, hin, zurück, quer durch die Republik. Finde ich voll schnell. Und klar, wenn ich jetzt wirklich tausende Kilometer weg bin, dann kann das schon mal etwas mehr werden, logisch. Aber auch das ist ok. Was ich hingegen ein wenig komisch finde, und da könnte ich schon die nächste Sache mit Verbesserungspotential präsentieren, ich weiß nur nicht, ob das sinnvoll ist, weil hier sagt ja schon keiner mehr was dazu, nun ja, das ist jedenfalls, dass ein Ruf, wenn er im LANCOM eingeht, also ein INVITE, sage und schreibe 750 ms braucht, um wieder raus zu gehen (10.12; 9.24:700). Eine dreiviertel Sekunde. Das gleiche noch mal in der Zentrale und man ist schon bei anderthalb Sekunden, also von ISDN war ich es gewöhnt, dass sobald man auf die Abheben-Taste gedrückt hat oder den Hörer nach vorheriger Eingabe der Nummer abgenommen hat, so gab es auch schon einen Freiton. Das ging so schnell, dass selbst wenn man sofort wieder aufgelegt hat, die Gegenseite schon einen verpassten Anruf hatte. Ich glaube kaum, dass die 750 ms dabei drauf gehen, da die max. 128 Einträge der Calls-Tabelle durchzugehen, denn das ändert sich auch nicht, wenn man da nur zwei Zeilen drin hat. Da muss irgendwas anderes nicht optimal laufen.

Viele Grüße,
Jirka

_________________
13 Jahre LANCOM-Forum — 13 Jahre Kompetenz in Sachen LANCOM.


Nach oben
 Profil  
 
BeitragVerfasst: 13 Apr 2018, 00:35 
Offline

Registriert: 20 Nov 2013, 10:17
Beiträge: 711
Hallo Jirka,

Jirka hat geschrieben:
Koppelfeld hat geschrieben:
Du hast dem Endkunden etwas versprochen, über das Du noch "verhandelst".

Nö, habe ich nicht. Wir, also der Kunde und ich, stellen nur fest, was die Praxis zeigt. Und wenn man das kritisch hinterfragt und genauer untersucht, dann zeigen sich derartige Sachen.

Nenn' mich altmodisch, aber ich habe den Endkunden nie als Betatester gesehen.

Zitat:
Eine dreiviertel Sekunde. Das gleiche noch mal in der Zentrale und man ist schon bei anderthalb Sekunden, also von ISDN war ich es gewöhnt, dass sobald man auf die Abheben-Taste gedrückt hat oder den Hörer nach vorheriger Eingabe der Nummer abgenommen hat, so gab es auch schon einen Freiton. Das ging so schnell, dass selbst wenn man sofort wieder aufgelegt hat, die Gegenseite schon einen verpassten Anruf hatte. Ich glaube kaum, dass die 750 ms dabei drauf gehen, da die max. 128 Einträge der Calls-Tabelle durchzugehen, denn das ändert sich auch nicht, wenn man da nur zwei Zeilen drin hat. Da muss irgendwas anderes nicht optimal laufen.

Früher, zu ISDN-Zeiten, war die Hardware um den Faktor 1.000 langsamer. Da hatten JAVA-Luschen, Muttersöhnchen und selbsternannte "Asperger-Autisten" gar keine Chance, abgesehen davon daddelten sie auf diesen ekelhaften Commodore-Brotkästen herum.
Der Job wurde von Leuten erledigt, die wußten, was sie taten. Tja, eine fette NIXDORF 8818 hatte als Zentralrechner einen --- ta-taaaaaaa: Z80H. Und ja, die war sauschnell, hatte ich auch unter den Fingern.

Das Problem ist von Niklaus Wirth treffend definiert worden: "Die Hardware wird langsamer schneller als die Software langsamer wird". Vulgo: Gib' einem "modernen Programmierer" 100% mehr Kapazität und Leistung, dann braucht sein Programm für die Ausführung nur das Doppelte der Zeit.

Deswegen sage ich immer: Eine schön gleichbleibend G - E - R - I - N - G - E Datenrate sorgt für wirkliche Fortschritte bei der herbeigejubelten "Digitalen Transformation". 6 MBit/s mit 2 MBit/s Upstream reichen für jeden Privathaushalt DICKE aus. Muß man eben auf Werbung und ähnlichen Sondermüll verzichten. Aber DANN würden wie Webseiten wieder schneller und funktional !


Nach oben
 Profil  
 
BeitragVerfasst: 13 Apr 2018, 02:46 
Offline
Benutzeravatar

Registriert: 03 Jan 2005, 14:39
Beiträge: 4010
Wohnort: Ex-OPAL-Gebiet
Hallo Koppelfeld,

wenn man Deine Postings so liest, tut man auch immer was für seine Allgemeinbildung. Wirthsches Gesetz - klingt interessant. Und muss man sich merken, schließlich unterliegt in der Tat fast jede Webseite diesem Gesetz...

Im Falle des VCM weiß ich nicht, ob das da tatsächlich auch der Fall ist. Im Callmanager-Trace sieht man:
Code:
[Callmanager] 2018/04/13 02:13:53,507 [CALL-INFO] : Construct CallInfo(06794480) 1
[Callmanager] 2018/04/13 02:13:53,507 [SIP-CALL] : cSipCall constructor (type 2) --- call=06794480, MediaStub=06794960, SIP call-id=2439335713@00a0572e9685, Cld: 01713332211
[Callmanager] 2018/04/13 02:13:53,507 [SIP-Provider] : - info       : got more than one digit, number potentially complete, start short overlap timeout
[Callmanager] 2018/04/13 02:13:53,507 [Sip-UA] : - info       : Reply code: 1
[Callmanager] 2018/04/13 02:13:53,507 [Sip-UA] : - info       : Marked user as busy
[Callmanager] 2018/04/13 02:13:54,257 [SIP-CALL] : Overlap timeout, call-id=2737
[Callmanager] 2018/04/13 02:13:54,257 [SIP-CALL] : - info       : called-id is '01713332211'
[Callmanager] 2018/04/13 02:13:54,257 [SIP-Provider] : -----[ INFO REQUEST, call-id=2737

Aber warum wurde hier ein Overlap timeout eingefügt? Ich brauche keinen. Hier werden nur vollständige Nummern gewählt, die auch gleich gerufen werden sollen. Wenn ich in der SIP-Leitung Overlap-Dialing aktiviere, ändert sich das Verhalten auch nicht. Komisch.
Man kann unter /Setup/Voice-Call-Manager/General den Parameter Overlap-Timeout konfigurieren, aber der steht da auf 6 Sekunden und ist eigentlich der Timeout, der bei ISDN verhindern soll, dass schon vor Ende der Eingabe der vollständigen Rufnummer gewählt wird (verhindert bei Einzelwahl (im Gegensatz zur Blockwahl) das Wählen der Rufnummer vor derem tatsächlichen Ende).

Viele Grüße,
Jirka

EDIT: Wirthsches Gesetz für Koppelfeld mit einem Link hinterlegt

_________________
13 Jahre LANCOM-Forum — 13 Jahre Kompetenz in Sachen LANCOM.


Zuletzt geändert von Jirka am 13 Apr 2018, 11:51, insgesamt 1-mal geändert.

Nach oben
 Profil  
 
BeitragVerfasst: 13 Apr 2018, 07:06 
Offline

Registriert: 20 Nov 2013, 10:17
Beiträge: 711
Öh, Vorsicht:
Das Zitat und der Autor passen zusammen (aus den frühen 90ern, als er 'Oberon' entwickelt hatte), aber das "Wirth'sche Gesetz" habe ich mir genau so ausgedacht wie die "Komplementärmenge".

Tja, und 'Overlap Dialing' implementiert man ja auch nicht.

Manchmal benötigt man eine Art 'Digit Collection', die
- entweder direkt durchstellt, wenn sie die Durchwahl '0' sieht,
- auch dann direkt durchstellt, wenn die maximale Anzahl der durchwählbaren Stellen erreicht ist,
- aber innerhalb der Durchwahl ein 'inter-digit timeout' von mindestens einer Sekunde gewährleistet.

Sonst kann es Dir passieren, daß Du via ISDN aus Bielefeld erreichbar bist, aus Steinhagen jedoch nicht. Ham' wir alles schon geübt.

Auch hier sehe ich den Fehler -sorry- eher bei Dir.
Der VCM ist keine TK-Anlage!
Wenn Du eine leistungsfähige Telephonie brauchst, dann
- nimm ein Asterisk oder Freeswitch oder Kamailio
- setze einen schönen Router davor (die 1906 werden Dir gefallen)
- verpasse dem TK-Server im Perimeter eine öffentliche IP
... and you're done.

Wenn Dir das zu stressig ist und irgendein Vollidiot einen SIP / ISDN - Gateway will: PATTON 463x für BRI oder PATTON 4960 für PRI. Einarbeitungszeit nicht zu kurz ansetzen.

Und, ganz wichtig, bestimmte Produkte meiden wie der Teufel das Weihwasser, ibs Snom, Starscheiss, 3CX, Askotzia und erst recht alles, wo die Buchstaben f,r,i,t,z enthalten sind.

Und KEIN Gigaset, KEIN "Easybell". Ganz sicher auch noch kein Telekom-VoIP, das GK-Produkt sieht ja ganz gut aus, braucht aber noch ein Jährchen der Reife.

Beherzige vor allem Nikolaus Wirths zweites Gesetz:
Er wurde 'mal gefragt, "Sie sind also der Meinung, 'small is beautiful'?", worauf er antwortete:
"Keineswegs. Aber: 'small is manageable'".

Dann hast Du Ruhe und Frieden.


Nach oben
 Profil  
 
BeitragVerfasst: 13 Apr 2018, 07:33 
Offline

Registriert: 20 Nov 2013, 10:17
Beiträge: 711
Ach ja, und damit sage ich nichts gegen den VCM!

Der ist halt etwas für die kleine WG oder den Privathaushalt oder den kleinen Handwerksbetrieb.

Würde man den VCM noch weiter einstellbar machen, dann passierte das gleiche Chaos, als wenn man eine UZI in den Schimpansenkäfig würfe.


Nach oben
 Profil  
 
BeitragVerfasst: 13 Apr 2018, 09:51 
Offline
Benutzeravatar

Registriert: 03 Jan 2005, 14:39
Beiträge: 4010
Wohnort: Ex-OPAL-Gebiet
Hi Koppelfeld,
aber ist das nicht etwas am Thema und meinem Problem vorbei, was Du hier schreibst?
Viele Grüße,
Jirka

_________________
13 Jahre LANCOM-Forum — 13 Jahre Kompetenz in Sachen LANCOM.


Nach oben
 Profil  
 
BeitragVerfasst: 13 Apr 2018, 10:48 
Offline

Registriert: 20 Nov 2013, 10:17
Beiträge: 711
Naja: Du erwartest vom VCM die volle Funktion eines SBC und einer PBX. Das ist aber nicht die Bestimmung des Produktes.


Nach oben
 Profil  
 
BeitragVerfasst: 16 Apr 2018, 11:44 
Offline

Registriert: 09 Dez 2004, 11:32
Beiträge: 168
Wohnort: Bonn
Hallo,

Koppelfeld hat geschrieben:
Und, ganz wichtig, bestimmte Produkte meiden wie der Teufel das Weihwasser, ibs Snom, Starscheiss, 3CX, Askotzia und erst recht alles, wo die Buchstaben f,r,i,t,z enthalten sind.

Und KEIN Gigaset, KEIN "Easybell". Ganz sicher auch noch kein Telekom-VoIP, das GK-Produkt sieht ja ganz gut aus, braucht aber noch ein Jährchen der Reife.


@Koppelfeld:

Kurze Frage: Welche schnurgebundenen IP-Telefone würdest du an einem asterisk betreiben?

Versprochen: keine Grundsatzdiskussion etc. oder weiteres Nachfragen.

Gruß und Danke,
Sebastian


Nach oben
 Profil  
 
BeitragVerfasst: 16 Apr 2018, 14:42 
Offline

Registriert: 20 Nov 2013, 10:17
Beiträge: 711
Wenn es um höchste Sprachqualität geht: Polycom.
Egal ob IP650, VVX500 oder das IP7000 - Konferenztelephon:
Das ist die Referenz.
Sehr langzeitstabil.

Bedienungsfreundlichkeit, gefällige Aussehen, sehr gute Qualität, viele nützliche Features:
Yealink T48S / T46S

Als Android-SIP - Telephon nehmen Kunden gern das Grandstream 3275.

DECT: Spectralink mir KWS 6500, 400 oder 8000.
und entsprechenden Handsets.


Nach oben
 Profil  
 
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 15 Beiträge ] 

Alle Zeiten sind UTC + 1 Stunde [ Sommerzeit ]



Ähnliche Themen
 Themen   Autor   Antworten   Zugriffe   Letzter Beitrag 
Es gibt keine neuen ungelesenen Beiträge in diesem Thema. Probleme mit VoIP über 1und1 und Lancom 1823 VoIP (Annex B)

biberman

7

2149

06 Mär 2007, 19:40

biberman Neuester Beitrag

Es gibt keine neuen ungelesenen Beiträge in diesem Thema. Problem mit VoIP Call Manager bei LANCOM 1722 VoIP

Commander

7

3389

06 Dez 2007, 17:27

Commander Neuester Beitrag

Es gibt keine neuen ungelesenen Beiträge in diesem Thema. LANCOM 1722 VoIP Fehlermeldung bei VoIP Anruf

atueting

9

3912

28 Mär 2006, 12:08

atueting Neuester Beitrag

Es gibt keine neuen ungelesenen Beiträge in diesem Thema. VOIP-Router 1724 - Probleme mit Verbindungsabbrüchen VOIP

protec

11

1358

06 Mai 2014, 16:05

protec Neuester Beitrag

Es gibt keine neuen ungelesenen Beiträge in diesem Thema. Fritzbox VoIP über LANCOM VoIP-Router

cguenther

6

2734

14 Aug 2016, 19:36

cguenther Neuester Beitrag

 


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
Powered by phpBB® Forum Software © phpBB Group